MVC - эвенты

[Godwarlock]

Всем привет. Немного врубаюсь в данный паттерн, но возник вопрос о например тач событиях. Где правильнее всего должна быть подписка на кнопки? Если во вьюшке, то я вынужден прибегать к выделению отдельного класса, в котором будет инициализирована подписка на все кнопки чтобы не замусорить отображение, в этой вьюшке, которая отправляет в контроллер сам факт нажатия. Но в чем суть контролера заключается? Если вся логика в модели, то у меня получается
View - отправляет запрос контроллеру, типо TouchEvent - _controller.setX();
Controller - setX()_model.setX();
Model - setX(); - тут логика и уже в обратку дипатч вьюшке.

Мне кажется тут что-то неправильно. Из вью ничего не передается контроллеру, только уведомление, что была нажата та или иная кнопка, собственно смысл реализовать TouchEvent внутри вью?
2) Если реализовать TouchEvent внутри контроллера, тогда он должен хранить ссылку на вьюшку, только ради получения ссылок на дисплей обджекты. Но в таком случае, мне не приходится из вьюшки, отправлять контроллеру, а тот в свою очередь в модель. Получается просто контроллер-модель. В этом случае, я вижу больше логику, чем когда реализуется TouchEvent во вью, потому то таким образом, не надо лишний раз обращаться к контроллеру. В общем как-то так, поясните по факту, как всё же грамотнее будет или может я что упускаю. С другой стороны, если во вьюшке создается 10 объектов, которые присылает модель, получается, вьюшка, должна оповестить контроллер о том, что было создано 10 объектов и следовательно, если оно надо, в контроллере подписать все эти 10 объектов. Тут тоже очень смутно всё видится.
И вот еще такой вопрос. Есть модель карты, есть модель интерфейса. Первая отвечает за всё, что связано с картой, отображение, удаление, сортировка, хранение и прочее. Модель интерфейса, хранит состояние тех же самых кнопок. Типо нажал на создать объект, у курсора появляется имедж и следует за ним(обработка слежения в модели карты), соответственно в модели интерфейса я ставлю флажок boolean isCreate. Но на этот isCreate, должна ссылаться модель карты, потому что если isCreate false, то модель карты обрубает обработку создания объекта на карте. Что это получается, мне надо передать ссылку модели интерфейса в модель карты? Будет ли это правильно? Или всё же мне надо просто расширить модель карты и перенести все состояния из модели интерфейса, в модель этой карты и вообще не разделять интерфейс от самого содержимого карты, ограничившись 2 вьюшками(ViewGUI,VewMap), 2 контроллерами(ControllerGUI,ControllerMap) и 1 моделью(MapModel).

[Wolsh]

Мне кажется тут что-то неправильно. Из вью ничего не передается контроллеру, только уведомление, что была нажата та или иная кнопка, собственно смысл реализовать TouchEvent внутри вью?

Cмысл в том, что Модель ничего не должна знать ни о каких "кнопках". Модель оперирует другими понятиями — действиями пользователя. КАК именно совершается действие — Модель не волнует. Контроллер как раз интерпретирует конкретные физические события Вьюхи "нажали клавишу S" в игровые события "пользователь совершил (запросил) действие ШагНазад". Вьюха, в частности, может предоставлять 15 способов совершить одно и то же игровое действие, и Модели не надо в этом разбираться, как и — внимание! — с тем, как Вью будет отображать изменения. Именно ради этой свободы и затевается MVC.

View - отправляет запрос контроллеру, типо TouchEvent - _controller.setX();

Вообще-то нет. Вью отправляет Событие. Тут такой момент, относящийся скорее к способу мышления. Пока ты пишешь так, что Вью приказывает Модели setX() через Контроллер, у тебя всегда будет этот немой вопрос "а нафига мне контроллер". Вот у тебя в пальце находятся нервные окончания. Представь, что когда ты к чему-то прикасаешься, они дают приказ мозгу "Отдернуть руку!". Это то, как сейчас устроен твой код. С такой системой отношений ты не сможешь сделать ничего своими руками, даже носки надеть или взять чашку кофе. Палец не должен принимать решения за твой мозг. Он должен послать сигнал "я к чему-то прикоснулся, оно горячее/холодное твердое/мягкое". А мозг, обладающий ВСЕЙ картиной окружающего мира, решит что с этим делать. Это тот же самый принцип иерархии, как в отношениях родитель/ребенок. Кнопка не приказывает, она извещает что ее нажали и всё. Вью не может приказывать Модели, потому что она не должна ничего знать о Модели* (кроме тех свойств, которые Модель предоставляет для отображения**). А какова роль контроллера в этом примере с пальцем? Считается, что контроллеры позволяют управлять Режимами (Mode). Вообще-то в концепции MVC предполагается, что контроллеров может быть тьма тьмущая, и они постоянно сменяют друг друга в зависимости от того, в каком режиме находится Приложение в данный момент — идет бой, идет строительство, игра на паузе, мы в Инвентаре, мы в Меню, мы читаем Дневник заданий, мы смотрим видеозаставку и т.п. Очевидно, что во всех этих режимах одно и то же действие пользователя "нажал клавишу Стрелка Вверх" интерпретируется совершенно по-разному. А эта интерпретация и есть задача контроллера, поэтому в разных режимах подключаются разные контроллеры. Как, например, ты касаешься пальцем чайника с одной четкой задачей — определить, насколько он горячий. В этот момент твой контроллер подписан только на два ощущения — касания и температуры. Его не интересуют твердость и влажность чайника.
_____________
* — Прежде всего потому, что Вью это ДисплейЛист, а ДисплейЛист это проститутка, предоставляющая полный свободный доступ ко всем своим детям. Зловредный код может выцепить любой объект через getChildAt() и послать от него любое событие dispatchEvent(). И пофиг, что в твоих классах ссылки на эти объекты запрятаны в приват.

** — чтобы скрыть остальные члены Модели, Вьюхе и Контроллеру предоставляется ссылка на Модель не как на тип Model, а на два разных Интерфейса. В Интерфейсе для Вью описываются только функции-геттеры свойств для отображения, а в Интерфейсе для Контроллера — функции-методы для управления Моделью. Таким образом Вью ничего не знает о методах, а контроллер не имеет доступа к свойствам (за исключением, может быть, каких-то специальных свойств для контроллера, обычно флагов).

[in4core]

Мне кажется тут что-то неправильно. Из вью ничего не передается контроллеру, только уведомление, что была нажата та или иная кнопка, собственно смысл реализовать TouchEvent внутри вью?

А кто мешает передавать ? передавай.

Вообще особо мудрить не стоит. Если приложение базируется на 1 контролле, то контролл делает только 2 действия - пинает сервер и записывает в модель. Вью работает и живет по своим законам, каким вам надо, главное чтоб не было ссылок на контрол, а на модель только на чтение ( хотя запись тоже доступна, но делать так незя).

Вот просто пример : жму кнопку на клаве, жопустим Интер - после чего, товарищ Якубович должен будет открыть нам слово. Что происходит : globalView -> hudView отслеживает нажатие клавиши, если никаких доп вещей в globalView не будет происходить, то через bubbles сразу отправляем событие в контролл. В контролле - вызов серверного метода, сервер отвечает, - получаем данные, открыта буква Д. Пихаем эти данные в модель, в самой же моделе идет проверка, если Д это последняя буква слова, то слово готово ну или типа того, не суть, вообщем работает логика. Соответсвенно модель после отработки логики - посылает событие во вью, где новые данные отображаются на экране, ЛИБО!!!!! - это может сделать контроллер!!! К примеру :

in Controll
_model.setData(serverSideData);
_view.update(someDiffrentDataNotOfModel)
----------
public function update(d:data):void  
{     trace(_model.newData)
      trace( d) 
}

[undefined]

В контролле - вызов серверного метода

Мне всегда казалось, что общение с сервером - работа для модели.

[in4core]

Мне всегда казалось, что общение с сервером - работа для модели.

Ваще не обязательно. Модель должна работать с данными, обрабатывать их - а не контролировать их обмен извне.

[Godwarlock]

Wolsh В общем по сути это своего рода автоматизация по системе событий. Должна ли модель слушать контроллер?

[Wolsh]

Модель никого не слушает, у нее ссылок ни на кого нет.

[Nooob]

Сообщение от in4core

Ваще не обязательно. Модель должна работать с данными, обрабатывать их - а не контролировать их обмен извне.

В моем идеальном мире:
Модель - это такая прослойка которая выдает текущее состояние, как она это состояние получила сама посчитала/от сервера получила/с диска прочитала это уже сугубо проблемы модели. потому что только объекты этой модели могут знать об актуальности/наличии/отсутствии своих данных. К примеру почта. Вью спрашивает данные о письмах у модели, модель смотрит ага, данных у меня нет, посмотрю на диске, на диске нет спрошу у сервера, пришли данные от сервера запишу их на диск и отдам остальным, при следующем запросе писем она посмотрит уже у себя и затем на диске и отдаст вьюхе. туда же можно докрутить слижение за актуальностью, к примеру если при запросе время последнего обновления писем меньше чем 1 сек то не спрашивать сервер, скорее всего ничего не поменялось.

Контроллер - эта прослойка выполняет роль контроля создания и взаимодействия с вью и хранит ссылку на модель. К примеру окно почты: оно сконструировано по инициативе контроллера, в конструктор передана ссылка на контроллер, при нажатии на кнопку обновить информацию о письмах она вызывает в обработчике события controller.executeMailUpdate(), где и описана логика обновления и всех необходимых проверок что можно ли в данный момент тревожить модель с этой просьбой (если обновлять нельзя то создает окно с ошибкой), и теперь предположим мы делаем туториал, где один из шагов научить пользователя работать с почтой, мы просто создаем другой контроллер наследник базового и переопределяем метод executeMailUpdate где к примеру запускается следующий шаг туториала. при этом мы не влезаем в механизмы базового контроллера и не модифицируем код модели, не модифицируем вью

Представление(Вью) - эта прослойка выполняет роль отображения текущего состояния и вызов нужных методов контроллера при действиях пользователя. Безусловно должен быть грамотно продуман цикл жизни вью, обычно он следующий конструктор(передали контроллер),awake(подписались на изменения модели данных (ссылку на модель можно получить из контроллера)),sleep(отписались), могут быть дополнительные шаги вроде update, finalize. В обработчике событий от модели изменяем текущее состояние (например очищаем все и заполняем заново). Конечно у вью может быть свое состояние и свои данные, например сколько соскролил пользователь в списке с письмами, чтобы при поступлении новых данных не сбрасывать скрол, но эти данные состояния живут во вью пока живет она, больше они не пригодятся. Если же все таки есть такие данные которые живут дольше (к примеру сохранять состояние прочитанных писем), то такие данные определенно должны храниться в модели.

Что касается темы то события ввода TouchEvent, MouseEvent это лишь специфика вью и их обработка должна находиться там так же как и специфика отображения, к примеру ты делаешь изометрическую карту на сцене и в углу мини карту упрощенную, то для обоих вариантов будет одна и та же модель данных. а свое внутренне состояние куда проскролилось, как отобразилось, как нажалось это уже обязанности вью.

[Godwarlock]

Спасибо всем за ответы, особенно Wolsh-у за очень грамотное толкование mvc и как оно должно по сути работать, мне прям вот этого вообще не хватало очень) Еще раз спасибо)))

[in4core]

Nooob - что то ваш идеальный мир - не очень то и идеален.
Хотя бы так : само слово модель это что? Пример - модель САМОЛЕТА. Модель грубо говоря завершенный экскиз, в котором можно менять детали, добавлять, удалять, с помощью ластика, например ( если модель на бумаге). Но эта модель простите сама не спрашивает у творца - как думаешь, зафигарить мне 3е крыло а? Ничего модель никому спрашивать не должна, я так считаю.