не получается идеальный MVC

[IDimitry]

Делая проекты и разделяя логику и данные, считал, что если не целиком реализую шаблон MVC, то хотя бы придерживаясь его базовых принципов, облегчаю процесс взаимодействия компонентов, а также делаю приложение более понятным и логичным. Однако, столкнувшись в последнее время с теорией (ранее как-то все на определния полагался), понимаю, что сильно заблуждаюсь, так как в моих реализациях как-то не могу, к примеру, полностью избавиться, чтобы модель не перебирала на себя часть функций контроллера, а представление - часть модели. Те интересные реализации - так сказать, идельные, которые нахожу, несколько простоваты и не отвечают полностью на мои вопросы - это и в блогах Флешера статья Котяры (спасибо ему), и заметки флоМастера (?), перевод и комменты реализации Мука - там часы с кнопками сделаны. В основном они представляют собой одно отдельно взятое представление, один контроллер, одну модель и не дают представление о, так сказать, идеальном взаимодействии множества представлений посредством множества контроллеров и моделей.

Просьба не посылать в вакансии - это всего лишь просьба помочь разобраться в структуре - сам чуть-чуть не дотягиваю. Уверен, что 98% посетителей форума или только слышали название, или имеют общие представления, или "слегка" заблуждаются в реализации (как я). Скажу честно, в идеале очень бы хотелось разобрать пример, где были бы представления типа Сцена, Элемент, Сокет, модели их поведения и взаимодействие. В "чистом" MVC как-то не получается. Может, кто-то сталкивался с примерами в инете (даже не на AS3), может, кто-то может предоставить очень-очень облегченный пример собственной реализации (кусочек проекта). Так заела эта тема, что не получается нормально двигаться дальше - все время приходится оборачиваться. Если выгорит с моей просьбой и я получу "чистый" MVC, обязуюсь отписать FAQ или блог "MVC стопами ньюба"

[etc]

Залезьте декомпилятором в Destiny (см. подпись), мне лень рассказывать

[Ромастый]

На мой взгляд, реализация "чистого" MVC - такая же утопия, как и тру-ООП.
Из серии сферического коня в вакууме. То есть к ним можно бесконечно стремиться, но после определенного момента на поддержание "чистоты" уходит значительно больше усилий и времени, чем на саму разработку.
Придерживаться основных принципов необходимо, но всегда есть конкретная задача, допускающая, а то и требующая (!!!) отклонений от стандартов и рамок.
Можно вспомнить одноименный фреймворк pureMVC, идеально подходящий для небольших проектов, требующий модифицирования и переделки под себя на проектах средней сложности, и становящийся жутко неудобным и негибким на здоровых проектах.
Кроме того, бывает ситуация (очень частая), когда трудно добиться четкого разделения контроллера и отображения, наоборот, удобнее и логичнее частично интегрировать их друг в друга. Так же, как код, написанный согласно принципам ООП, разбавить вкраплениями функционального программирования.

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

[terbooter]

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

обязуюсь отписать FAQ или блог "MVC стопами ньюба"

Я бы с интересом почитал.
Тоже много вопросов но нет времени (или лень?) разбираться самому.

[Cybo]

Я бы тоже с удовольствием почитал. Для меня до сих пор существует проблема разделения обязанностей между Моделью и Контроллером. Базовый механизм обязанностей мне понятен, с этим проблем нет, но вот частенько приходится долго думать, куда запихнуть тот или иной функционал.

[Nemo_c]

IDimitry,
Я бы даже поучаствовал в написании FAQ по mvc.

Пример не очень удачный, ПМСМ. Есть здесь

http://developer.longtailvideo.com/t...ediaplayer-4.4
http://developer.longtailvideo.com/t...ediaplayer-4.3


Инфа про MVC на java и с#

http://rsdn.ru/article/patterns/generic-mvc2.xml
http://rsdn.ru/article/patterns/generic-mvc.xml

некий обзор MVC есть здесь
http://www.phpwact.org/pattern/model_view_controller

про реализацию MVC на AS3 можно нарыть здесь.
http://www.ultrashock.com/forums/oop/

Видеоурок по MVC от Lynda.com
http://www.lynda.com/home/DisplayCourse.aspx?lpk2=759

[IDimitry]

Сегодня снизошло озарение
Думаю, завтра добъю базовую реализацию. Сделаю наброски и можно будет снова открыть дискуссию по обсуждаемому шаблону.

Правда, запал несколько угас, так как прихожу к выводу, что "чистый" MVC - это действительно только шаблон проектирования, но в реальной реализации зачастую приходится отходить немного от "идеала" из-за обсурдности последнего ...

Пример, с которым сталкивается буквально каждый и буквально с первых строк приложения: есть базовый класс (от Sprite или MovieClip), в конструкторе которого надо запустить некий setup проекта - назовем условно initialization. Как это просто и удобно делать? - Думаю, так делают буквально все:

this.addEventListener(Event.ADDED_TO_STAGE, initialization);

(проверку на stage можно еще не делать, так как вызов происходит в конструкторе, значит, на сцене базового еще нет).
Так ведь? И ниже прописываем функцию initialization ... Просто и удобно. Но это несколько противоречит рассматриваемому шаблону MVC: обслуживать события по некоим установленным шаблоном правилам должен контроллер, а вопросами инициализации (работа с данными) - модель. Ведь наш базовый класс в большинстве проектов является главным и зачастую глобальным контейнером - ну буквально Сценой. Соответственно, вывод в нем - Представление "сцены", обработка эвентов - Контроллером, правила поведения - Модель. И по правилам проектирования задавать правильнее было бы так:

this.addEventListener(Event.ADDED_TO_STAGE, controller.loadedToStage);

в контроллере "сцены" прописываем

public function loadToStage(event:Event = null):void {
	{reference to Model}.initialize();
}

а в модели уже производим инициализацию (initialize).
В защиту данного умозаключения (вывода) говорит также то, что непосредственно с данными "контактировать" может и должна только Модель. А фактически процесс инициализации - это как раз какие-то процессы, связанные с установками, данными и внешними данными.

Но на практике кто задумывается отдать обработку загрузки "сцены" модели, да еще таким замысловатым способом? Вот вам и цена "идеальности" шаблона. Надеюсь, нечасто прийдется сталкиваться с ситуациями, когда прийдется так проектировать только ради чистоты проектирования.

Nemo_c, спасибо за ссылки.

P.S. Сырой подход, сырые суждения, сырые выводы - просто хочу разобраться и замечательно отношусь к критике.

[BlooDHounD]

будь это "только шаблоном проектирования", у Вас бы не получилось "отходить немного от "идеала" из-за абсурдности последнего".

ну на addedToStage можно сделать тупо new Controller(), например.

на практике с данным контактируют все трое: контроллер данные записывает, модель хранит, вьюха отображает %)

+ Вы не учитываете комбо-элементы.

[mre]

IDimitry, а что, у контроллера нет ссылки на view?
Что мешает подписаться на ADDED_TO_STAGE в контроллере?

[tikhop]

а где должны храниться методы работы с сервером (AMFPHP, FMS) В модели?