Проблемы использования MVC

---

Проблемы использования MVC
(Черновик)

Концепция MVC очень привлекательна, и до некоторого временя я был ярым её приверженцом, и даже, мягко сказать, фанатом)
Но, переводя старые проекты на этот паттерн, и проектируя новые, я столкнулся с некоторыми проблемами, которые я попробую описать и формализовать.
Часть примерных решений проблем я опишу, часть остаётся открытыми. Прошу помочь!

Целью статьи является ФОРМАЛИЗАЦИЯ проблем при разработке архитектуры проекта, если вдруг пришло в голову использовать MVC (готовый или самописный)


В статье попробую описать проблемы конструирования проекта и реализации MVC для ActionScript3, с которыми сталкивался лично, хотя многие проблемы не связаны напрямую с языком, и, скорее являются проблемами архитектуры в чистом, незамутнённом реализациями, виде, или, что более вероятно, проблемами моего восприятия концепции MVC)
Я пока не знаком со всеми реализациями MVC, ссылки на которые указал ниже, возможно, в некоторых из них многих проблем не существует.

И вообще, как сказал wvxwv:
Хотя использовать по новой в ОДНОТИПНЫХ проектах можно и нужно.

Вводная:
TODO: описание MVC - примеры реализаций, ссылки.
Существует множество реализаций MVC, как для pure AS3, так и для Flex.
вот некоторые из них:
TODO: добавить краткий обзор каждого, и ссылки на документацию.

* Cairngorm
http://opensource.adobe.com/wiki/dis...gorm/Cairngorm

* PureMVC
http://puremvc.org/

* Mate
http://mate.asfusion.com/

* HydraMVC - A rewrite of the PureMVC API exclusively for Flex
http://www.hydramvc.com/


* Slide
http://code.google.com/p/flex-slide/

* Guasax
http://www.guasax.com/

* Parsley
http://www.spicefactory.org/parsley/

* FlashMVC - A flexable lightweight framework engine for AS3.
http://www.flashmvc.com/

* Hive - A state-based MVC framework for AS3.
http://code.google.com/p/as-hive/

* Soma and SomaUI - An AS3 MVC framework and software to generate an AS3 flash site based on it.
http://www.soundstep.com/blog/downloads/somaui/


Самая основная проблема:
0. А нужен ли MVC вообще в этом, конкретном проекте:
TODO - плюсы и минусы MVC, проекты где без MVC не обойтись/ проекты где MVC лучше не использовать.


Проблемы отделения:

1.Отделение контроллера от вида
Отделить контроллер от представления обычно легко - в качестве контроллера у меня часто выступает некий parent - это может быть документ класс или составной VC (подмодуль).Фанаты явно отделяют контроллер от основного вида используя композицию.
На самом деле Фасад (F)- по сути является контроллером, хотя с другой стороны является видом более высоко порядка. В иерархическом MVC я не вижу смысла отделять Фасад

2.Отделение модели(M) от вида(V).
Собственные данные вида, такие как x,y - очень часто выглядаят как данные модели, и возникает соблазн не заводить их в модели и менять напрямую из контроллера. После таких конструкций более логично выглядит и остальные данные привязать напрямую с видом. Этого делать нельзя, но очень хочется - значит можно.
Пример:
добавляем вид слушающий x,y модели. но модель не изменяется, соответственно нет события изменения.
Решение 1: вызов view.init() - > самостоятельное взятие данных из модели..
Вроде хорошое решение, но из этого решения вытекает проблема №7

3.Отделение модели от контроллера(C)
тут не так всё однозначно.. часто событие обновления данных модели напрямую меняет виды.

Проблемы иерархий:

4. Синглтоны
5. Иерархия вложенных MVC

6. Изменение связанных данных модели поочерёдно.
Поясню проблему примером:
Изменились x,y - вид слушает оба изменения. т.е. ловит два соытия и оба раза изменяет своё состояние..
Решение: связанные данные связывать)) т.е. менять не x,y, а Point.
Другой вопрос, что


Проблемы ссылок:
7. Всегда ли вид должен иметь ссылку на модель, как объект содержащий данные, или только как объект раздающий события?

Управление сложностью:
8. Создание множества лишних классов.
концепция MVC плодит множество классов и соответствеено увеличивает СЛОЖНОСТЬ, как понятие надёжности.

пример: надо сделать движение 10 шариков по экрану. координаты шариков приходят с сервера(имитация в Main.serverOnData).
без mvc : класс Main добавляет 10 шариков Ball. Main вызывает ball[i].move(xArr[i],yArr[i]). всего 2 класса,11 стационарных объектов.
TODO: код,вложения.

mvc: класс Main (FC) создаёт 10 объектов BallView, один MainModel и 10 BallModel. затем связывает каждый ballView и ballModel.
Каждый ballView подписан на событие BallModelEvent.CHANGE_POINT создаваемое в ballModel.
Main изменяет MainModel.ballModelArray
итого:
TODO: код,вложения.

Проблемы взаимодействий интерфейсов
10. ~7+ иерархические модели
..

Проблемы производительности
20. Проблема вызовов.
лучше в одной ф-ции (render) напрямую поменять виды чем изменять модели, и ждать событий изменения.

Проблемы состояний и отложенных действий.
30. Где хранить промежуточные данные? в контроллере?
пример
от сервера приходит действия: шарику двигаться на x1, затем на x2, потом показать табличку, затем плавно поменять счёт.