MVC: грамотная архитектура проекта

[Котяра]

а просто не раз попадались предложения не лукавить и делать напрямую. Признать, что на самом деле, особенно если говорить о конкретном проекте, Вью пишется для Модели, а не ЛюбойМодели, а Контроллер пишется для Вью — по сути, для каждого Вью. И что разнесение их с помощью Событий звучит красиво, пока рассматривается пример с одним кликом по кнопке. Но в случае игры появляется 100500 уникальных типов событий, к тому же несущих в себе данные, и ежу понятно что Вью, посылая событие, рассчитывает на реакцию, а Контроллер обязан знать именно этот конкретный тип события, что хочешь-не хочешь а создает сильную связанность Вью и "его"(!) Контроллера и плодит бесконечные классы Событий, иногда описывающих одно-единственное действие во Вью. И как альтернатива предлагается отказаться от Событий между Вью и Контроллером, заменив ОБЩИЙ СПИСОК событий Интерфейсом Контроллера, дергая его методы напрямую. То есть Вью "ожидает" весьма конкретный контроллер, понимающий все задачи Вью. И я склонен соглашаться, что иногда в конкретных проектах в этом нет ничего дурного. Очень радует фраза GoF в их книге о паттернах, когда они рассказывают концепцию MVC в начале книги и приводят Схему MVC с примечанием: "на Схеме не показаны Контроллеры для простоты понимания". Вот как-то так. Контроллер — всего лишь придаток Вью, собирающий в одном месте, удобном для редактирования, логику взаимодействия Вью с Моделью, позволяя в собственно Вью сконцентрироваться только на визуалке. Этакий набор методов Вью для дерганья Модели, чем по сути контроллер и является.

И чтоб в моих проектах такой фигни не встречалось я просто добавил класс медиатора.

Wolsh, Дюк, именно, эта схема описывается в MVVM или PresentationModel (по Фаулеру)

PS. не увидел, что тема уже закрыта.
удаляюсь.

[dimarik]

Не, я требую продолжения банкета! Почки один раз царице!

[Котяра]

Почки царице - больше одной почки никак не получится.
Но давай продолжим.
Давайте лучше обсудим подходы и разницы между PM, MVVM и концепцией медиаторов принятых в робоногах и пуреМВЦ.
Также, давайте затронем тему иерархической МВЦ и способов инжектирования зависимостей.
Да и просто принципы Инверсии управления.

[Dukobpa3]

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

Не нравится:
1. пюре - олбсервер с одной шиной, могу из контроллера послеть в модель, хотя зачем. Так же из модели могу послать команду, вырвиглазие получается.
2. пюре - если работать одному или 2-3 человека с грамотным лидом - глобальный синглотоновый домступ круто, ибо легко контролировать не отклоняясь от идеалогии. В болшой команде очень легко выстрелить себе в ногу, поэтому сам вполне таки подходы одобряю, в ентерпрайзе ни-ни. Надо делать нечто более ограниченное и зашоренное.
3. То же что и в п.2 относится и к РЛ.

А вцелом то че. Любой инструмент просто инструмент. Главное как им пользоваться. И из пюре реально конфетку собрать со всеми его глобальными обсервера и синглтонами. Только надо понимать зачем.

//*******************
еще:
Люблю одноуровневые модели. Если дерево - то уже чуть другая структура полдучается. На одном уровне модели. а потом внутри каждой еще какие-то структурки есть, но эти структурки по сути уже не модели с точки зрения какого-либо фреймворка, это просто группы данных.
Вообще не одобряю дерево контроллеров. Если допустим вью и модели можно сделать как два зеркальных взаимодополняющих дерева - это круто.
А вот контроллеры в деревья складывать вообще не понимаю зачем, хотя видел такие реализации.

Ненавижу паттерн команда, как в пюре. Там где должен быть контроллер - там лучше юзать контроллер. Весь проект на командах это неуправляемая опа. Зато люблю использовать этот паттерн в месте общения с сервером. Если с сервера прилетела команда - то вполне логично сделать ее командой. Чтоб сама себя и выполнить могла. РПЦ в чистом виде. В любых других реализациях хз. Готов спорить.

[Wolsh]

Wolsh, Дюк, именно, эта схема описывается в MVVM или PresentationModel (по Фаулеру)

А, вот где я это видел)))

Мне, признаться, не очень понятны медиаторы. То есть когда читаешь (у тех же GoF, например), теоретически все понятно. Но на практике применить не удалось (может, не очень хотелось). Было бы интересно разобрать какой-то минимальный практический пример, хотя бы на словах (ибо понимаю, что кода будет несколько классов).

[Akopalipsis]

Давайте лучше обсудим подходы и разницы между PM, MVVM и концепцией медиаторов принятых в робоногах и пуреМВЦ.

Почему то мне кажется, что ЭТИ моменты будут скучны... Это же про них надо читать..
А если кто и прочёл, то он подумает, а зачем мне надо рассказывать... Я ЖЕ ЧИТАЛ!
А вот если по теме, то как было сказано ранее, если я правильно понял, то MVVM - это ссылка на контроллер во вью. Вот как я это вижу - одни прелести, на каждый вид своя маленькая моделька и свой маленький контроллер. Главная модель становится создателем маленьких моделей, после создания диспатчит события главной вью. Та создает маленький вид и при добавлении на стейдж активирует свой маленький контроллер. Как мне кажется, такой вариант, оставляем меньше шансов сделать что то "Толстое" и легко редактировать и заменять.

Добавлено через 31 секунду
Попёрло!!!)

[in4core]

Akopalipsis - не нужно вам ничего видеть, вам нужно писать. Сразу оговорюсь - когда первый раз начал разюирать МВС - сразу же попался мне пример с ссылкой на контроллер, причем даже приложение было целое, было можно и поковыряться. И по началу я тоже подмывал - неплхая штука. Со временем забудите как страшный сон, но только когда напишите одно приложение ТАК, а другое как положено. Руки захотят добра. Да и вообще по сути, в простеньких приложениях задумываться об контроллерах редко приходится, как пишет Дикобраз - на один раз и забыл о них. - ну так оно и есть

[Akopalipsis]

in4core я не спорю, я просто говорю то, что кручу в голове, чего мне пока не хватает. Хоть я и делаю первое "нечто" ( дошёл до анимации ), то уже сейчас хочу вот что сказать, обсервер - обсервером, но мне почему то в голову идёт переделать немного EventDispatcher так, чтобы классы были в виде обычных, чтобы они не были зависимы от конкретного приложения. Так же мне хочется использовать для удобства "красивые константы", но тогда получится, что единственный контроллер утонет после моего сумашедстви и я в нем запутаюсь. А так, у меня грубоГоворя, папка_кнопка и я знаю, что в ней и вид и контроллер и если надо моделька...

[in4core]

чтобы они не были зависимы от конкретного приложения

Ура! наконец то вы дошли до понятия совершенный код и идеальный велосипед! Срочно бросайте эти экстремистские забавы - пока совсем плохо не стало

[Dukobpa3]

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

Мне, признаться, не очень понятны медиаторы.

А в чем конкретно вопросы и что не понятно на практике?
Медиаторы становятся понятными когда используется тяжелая составная вью. Например какая-то изометрическая карта города.
Тогда удобнее сделать несколько вьюх, и все их объединить одним медиатором. Банально улучшается управляемость кода, классы меньше и лучше инкапсулированы. Но это возможно не совсем удачный пример так как его можно разрулить и просто грамотной организацией самой вьюхи.

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

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

//********************
Это примеры из моей практики, либо, как с изометрической картой - проблемы, с которыми столкнулся, но на тот момент решил кривовато, ибо не догадался использовать медиатор.