И снова MVC
 

Читал статейки, на их примерах все прекрасно. А у меня все через одно место ))) Вообщем, вопрос по поводу Вьюшки. Как я понимаю доступ к сцене (или сценам) должна иметь только Вьюшка, тогда такой вопрос: Вьюшка слушает событие нажатие клавиши движения, передает его в Контроллер, Контроллер решает как изменить модель, и меняет ее координаты (т.е. мой мувик уже переместился). Модель издает событие, что она изменилась, которое слушает Вьюшка. Вроде все прекрасно, но ... Что должна сделать Вьюшка после того как она узнала, что Модель изменилась??? Ведь и без нее все прекрасно работает! Помогите пожалуйста, очень запустался в этом паттерне.

Ничего подобного. И как только ты это осознаешь — сразу поймешь, что должна делать вьюшка, когда узнает, что в модели для нее уже уготовано новое место.

Читайте http://www.flasher.ru/forum/showthread.php?t=138349 Это в разделе "Статьи". Незачем очередной MVC флуд разводить. Там все разжевано, все вопросы заданы, и все ответы на них получены. Главное прочитать.

Они были бы получены если бы была одна концепция MVC на весь мир. А вариаций MVC более 9000 и каждый адепт считает что его MVC самое правильное (МVC , MVP, МVVМ). Причем внутри подмножества MVC тоже много вариантов разделения обязанностей, и в MVP тоже, причем некоторые вариации непонятно к какому подмножеству больше относятся.

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

Как должна выглядеть цепочка действий описанная в топике:
Вьюшка отловила нажатие клавиши - вызвала метод контроллера - контроллер поменял координаты модели - модель послала событие - вьюшка прослушала событие и изменила координаты.

Зачем нам модель? Почему сразу в контроллере вьюшку не поменять?
- А вьюшек для одной и той же сущности может быть несколько (для машинки - отображение в изометрии, отображение на уменьшенной карте, отображение параметров в диалоговом окне - и все на одной модельке) - как бы контроллер выглядел, если бы ему пришлось одни и те же данные по всему этому хозяйству распихивать?

Зачем нам вьюшка?
- Ну тут все понятно

Зачем нам контроллер - давайте запихаем логику в модель или во вьюшку
(это, ИМХО более тонкий момент и часто так и делают и это оправдано)

1. Если мы запихнем логику во вьюшку - это может привести к росту копипасты
Например, перемещение персонажа при указании цели на измометрической и на уменьшенной карте - если мы пишем это во вьюшке - и там и там будет один и тот же код.

2. Если мы запихнем логику в модель - мы потеряем гибкость. Например в режиме строительства при клике на карте - появляется диалоговое окно с выбором здания и далее начинается строительство. А в нормальном режиме - при клике на здании, с него например, собираются деньги
Это 2 совершенно разных действия с вроде как одной моделью - зданием. И если все новые действия пихать в модель, то мало какой супер-мозг сможет это поддерживать.

Вот вобщем-то и все.

P.S. Встречался с альтернативной концепцией, которая, однако, успешно работала, правда приводила в ужас своей "смелостью" и были некоторые проблемы, решаемые только затычками
Собственно вот она:
1. Сращиваем модель с вьюхой намертво (т.к. вьюх много - выбираем приоритетную - отображение в изометрии и записываем все данные прямо на ней с прямым изменением отображения)
2. Остальные вьюхи используют это ViewModel аки нормальную модель.
3. Контроллер, небольшая часть которого размазана по "чистым" вьюхам (но это и в true-MVC случается), частично представленный в виде отдельных синглтонов, который используют эти ViewModel-ки, частично интегрирован в ViewModel.

Странное допущение "чтобы не запутаться". Мы говорим о том, что вьюшка на уровне приложения ссылается на контроллер, хотя контроллер весьма явно ссылается на вьюшку на уровне кода.

Сегодня напрямую столкнулся с ещё одним очень интересным паттерном, развивающим MVC - это Presentation Model.
Это, как мне кажется, развитие MVP, где Presenter во многом отказывается от своей контроллирующей сущности и, если от видов не нужен отклик, может совсем и не иметь ссылок на виды (вернее иметь только для оповещения)
Суть в том, что PM выступает в роли промежуточной модели.
Вот хорошее сравнение (хотя и на примере C#, но всё понятно)
Канонический пример Фаулера.
А вот реализация на Flex. (пример и исходный код)
В микрософтах этот паттерн получил развитие как MVVM

Ну этого нигде нет, единственная связь вида с контроллером - для посылки сообщения.. т.е связь по интерфейсу обсервера(эвентдиспатчера)

Это, Psycho Tiger, о чём я и говорил - каждый считает что его представление о MVC самое правильное :)
Я даже поспорить не могу, потому что не уверен, с позиций какой концепции ты смотришь.

А они все, эти концепции работают с одинаково переменным успехом для разных ситуаций

У нас было в одной игре и зашибись работало, да и вот на картинке вьюшка ссылается на ViewModel, которая работает почти как контроллер

Я бы не один из этих вариантов в абсолют не возводил:
Вложение 26642

expl, я с вами полностью согласен, и очень рад что кто-то это написал. :)

А то тут все ссылаются на:
http://www.flasher.ru/forum/showthread.php?t=138349
когда там многое сугубо субъективно, и не отражает классического паттерна.

Ну кто вам сказал, что классический паттерн - это идеально?
У него много недостатков, и развитие в виде MVP, PM, MVVM он получил не просто так.
А ссылка, как раз на обсуждение классической реализации.
Ну и expl вообще говорит, что не заморачивайтесь и делайте как надо в конкретном случае.

Я один понял, что название темы не отражает сути вопроса и противоречит правилам названий тем, принятых на нашем форуме?