Должен ли вид быть IEventDispatcher'ом?
 

Мы тут недавно поспорили по этому поводу, но, хотелось бы услышать еще мнения.
Я думаю, что нет, другая сторона думаeт, что да.
Мои доводы:
Примеры классы Graphics и BitmapData, которые вполне подпадают под описание "вида" по моему мнению. + другие "самодельные" виды, типа как например управление HTML элементами страницы, или запись файла, который тоже может быть видом для другого приложения.
(Все, опять же только мое мнение).

Доводы другой стороны:
Флеш на 99% рассчитан на работу с дисплей объектами, и подписываться на события от них - это как бы в порядке вещей, и вообще удобно. + возможность диспатчить в них события типа "бродакаст" делает подход к проблеме несколько более универсальным. + одинаковый подход к работе с видом, т.как любой вид можно представить, как один и тот же интерфейс, не вдаваясь в конкретику. + это несколько упрощает планирование. Так, например, если апдейты во вью не моментальные, то мы легко решаем проблему асинхронности апдейтов.

Вобщем, хотелось бы услышать ваши мнения.

Мне кажется, что, если мы говорим всё-таки о флеше, то здесь как минимум 90% видов наследуют от класса, реализующего этот интерфейс. Поэтому поводом к неиспользованию IEventDispatcher могут стать только существенные недостатки, которые это использование за собой повлечёт. Какие преимущества даёт использование этого интерфейса, вы только что подробно рассказали :) Серьёзных недостатков я не вижу. Да, идеологически немного неправильно, но только немного, и проявляться это будет нечасто. Так что, думаю, должен (вернее, стоит).

Я думаю да, конечно.
Любой вид должен имплементить этот интерфейс
Не согласен. Если вы что-то видите, вы должны уметь это "потрогать".

не соглашусь что BitmapData подпадает под описание "вида". это объект с данными, о чем нам и сигнализирует суффикс Data.

Graphics же - просто интерфейс (тоже не "вид")

я не думаю что это критично (Должен ли вид быть IEventDispatcher'ом), так как вид главным образом должен служить для отображения данных и если от него не требуется обратной связи (например регистрация действий пользователя) то нафига спрашивается ему быть диспатчером?
wvxvw, я за тебя :)

Просто когда мы это примеряем на флеш, то нам подход с дисплей объектами кажется очевидным, но, флеш это все таки не единственое место, где MVC имеет место быть :), в том же PHP существует точно такая же парадигма, и там как-то никто не предполагает, что вид будет дисатчить события обратно... Как правило предполагается в него просто сеттить чего-нибудь.

Да, может быть Graphics не самый удачный пример, птотому что он не расширяемый, а вот BitmapData вполне, как на мой взгляд может выступать в качестве вида - банальный пример:
Рисуем графику в битмапдату и передаем ее серверу на сохранение. В этом случае нашим видом будет битмапдата... Как бы интерфейс он же не обязан быть с пользователем, он может быть и с другой программой.

А через что кроме вида можно получать события от пользователя? Лишив вид возможности рассылать события, мы лишаем приложение всякой интерактивности.
Если же вид является просто отображением, а не интерфейсом, то тогда он вполне может обойтись без рассылки событий.

GAIKER верно высказался, я тоже не совсем понял идею лишать вид диспетчеризации.
А броадкастинг очень плохая затея. Пользуясь броадкастингом можно запутать все связи между составляющими.
Каждый объект должен знать свое место и не знать ничего о тех к кому он не имеет отношения.

wvxvw, что-то не вяжется твоя теория о том, что BitmapData - это представление. в твоей схеме представлением является сервер :) контроллер заполнил модель ( BitmapData ) и отдал представлению ( сервер ).

а по поводу IEventDispatcher... необязательно представление должно его реализовывать. просто в АС3 у тебя не получится иначе :) зато в том же пыхе, у тебя это получается. хотя если результатом работы скрипта является HTML, то в итоге ты получишь IEventDispatcher только браузеровский.

IEventDispatcher нужен только в том случаи, если контроллеру нужен callback от представления. хотя некоторые евангелисты предпочитают использовать функции-свойства вместо событий, типа быстрее и круче.

Ну битмапдата, имелась в виду, например, такая ситуация:
У нас есть русунок, есть его представление в векторном виде - это бишь модель. И есть его представление в виде пиксельной картинки. Эта картинка вообще не является частью интерфейса, например, карта, куда пользователь кликал за время пребывания на сайте. С точки зрения сервера картинку можно рассматривать как модель, но на клиенте это все таки будет вид ИМО.

И это я не против наличия свойств диспетчера в виде, я против того, чтобы, например контроллер вcегда предполагал, что вид является диспатчером. Т.е. должен ли контроллер: