Цитата:
|
Там все разжевано, все вопросы заданы, и все ответы на них получены
|
Они были бы получены если бы была одна концепция 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.