Хорошее MVC

[Psycho Tiger]

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

Оригинальное сообщение:
Раньше делал жалкие подобия (хотя сложно назвать и подобиями) - например, вьюшка создает модель, то есть совсем всё плохо - теперь хочу начать делать грамотно. Наслушавшись etc про то, что PureMVC гавно и wxvxw про то что MVC вообще не может быть фреймворком (с последним согласен полностью - не понимаю, как архитектуру можно обернуть в универсальный фреймворк) встаёт вопрос - а как сделать правильное MVC? Гугл внятного ответа не дал, лишь что модель хранит и обрабатывает все данные, вьюшка отображает, а контроллер связывает эти 2 штуки.
Собственно, помимо просьбы дать статьи на правильный MVC ещё прошу объяснить вот какие моменты:
1) Кто кого создаёт? (для простоты будем отправной точкой брать базовый класс) - базовый класс создаёт контроллер, который создаёт вьюшку и модель, или как вообще? (может написал глупость, просто совершенно не понимаю кто кого - лишь для наглядности примера, что я хочу узнать)

2) У кого должны быть на кого ссылки и у кого не должны быть?

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

4) M+VC, VM+C - в чем разница?

5) В случае появления базы данных, кто с ней работает и кто имеет на неё ссылки?

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

[fljot]

хз)

Новая хрень появилась — RobotLegs зовётся, попробуй подёргать её за всякое.

http://www.robotlegs.org/
http://shaun.boyblack.co.za/blog/200...ework-but-why/

[etc]

1) Контроллер создает и модель и вьюшку;
2) http://www.flasher.ru/forum/showpost...54&postcount=2
3) Рутовый класс создает рутовый же контроллер и передаёт ссылку на самого себя как на контейнер вьюшек. Всё;
4) M+VC — контроллер интегрирован во вьювер. В общем-то, это контрол. VM+C — вьювер с интегрированной моделью. В принципе это ItemRenderer, по идее;
5) Отображает вьювер, изменяет контроллер. И у того и другого есть ссылки на базу.

[Psycho Tiger]

1) Так, хорошо. А если вьюшку создаёт он сам, то как её добавить? Диспатчить кастомное событие?

2) Да, медитировал на схему ещё давно, однако она мне кажется слишком сложной и поспешной для выводов, но я попробую сформулировать постулаты, и чтобы не утруждать вас лишней писаниной буду рад просто плюсикам над правильными высказываниями:
а) Самый главный контроллер создаёт ещё кучи контроллеров
б) Контроллер так как создал модель имеет ссылкой и вьюшку, и модель
в) Вьюшки порождают вьюшки... А кто их контроллер и где их модель?

Дальше, если представить что Data=модель
г) view events - событие о том, что вьюшку нужно обновить? Обычное бабблинг событие? Но ведь бабблинг событие ~31 раз в секунду достаточно ресурсоемко - как же быть?

4) это мне понятно, мне не понятно с точки зрения реализации. M+VC - связь с моделью напрямую из вьюшки так? А каокй толк в VM+C?

И появился новый вопрос - а где происходит вся логика? В Модели? То есть модель - эта вся логика, а контроллер призван помочь вьюшке отобразить это, верно?

[etc]

1) Добавить куда? Есть ссылка на контейнер для вьюшек;
2)
а) Не всегда, младшие контроллеры могут ещё более младших создавать;
б) Не понял;
в) Снаружи, на них ссылаются. Вьюшке максимум отдается ссылка на модель-контейнер;
г) Нет, view events — события от вьювера. Например MouseEvent.CLICK. А какая связь между ENTER_FRAME и бабблингом, я не уловил;
4) Модель обычно не имеет ссылок ни на вьюшек, ни на контроллеры, она сама по себе. Равно как она и не содержит логики, логика находится в контроллера. Задача модели — хранить данные и уведомлять об изменении.

[Psycho Tiger]

Спасибо, начинаю понимать.
1) Я так понимаю в контроллер всегда передаётся DisplayObjectContainer, говорящий куда пихнуть вьюшку?
б) я имею ввиду что раз контроллер создаёт и вьюшку, и модель то он сохраняет их ссылки. Ну в принципе вопрос риторический, не сохранять было бы глупо.
в) а как можно ссылаться снаружи на то, что было создано внутри? Диспатчится событие и на неё начинают ссылаться?
г) теперь понял что это, думал о другом =)

Такс, применив свои знания набросал это в коде, посмотри пожалуйста:
Базовый класс:

package  
{
	import flash.display.Sprite;
 
	public class JustMain extends Sprite
	{
 
		public function JustMain() 
		{
			super();
			var controller:Controller = new Controller(this);
		}
 
	}
 
}

Контроллер:

package  
{
	import flash.display.DisplayObjectContainer;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Controller
	{
		private var _model:Model = new Model();
		private var _viewer:Viewer = new Viewer();
		private var _container:DisplayObjectContainer;
		public function Controller(container:DisplayObjectContainer) 
		{
			_container = container;
			init();
		}
 
		private function init():void
		{
			_container.addChild(_viewer);
			_model.addEventListener(Event.CHANGE, onModelChange);
			_viewer.addEventListener(MouseEvent.CLICK, onViewerClick);
 
		}
 
		private function onViewerClick(e:MouseEvent):void 
		{
			_model.change(Math.random() * 400, Math.random() * 400);
		}
 
		private function onModelChange(e:Event):void 
		{
			_viewer.updatePositions(_model.x, _model.y);
		}
 
	}
 
}

Моделька:

package  
{
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IEventDispatcher;
 
	public class Model extends EventDispatcher
	{
 
		//no getters/setters, just example
		public var x:Number = 0;
		public var y:Number = 0;
 
		public function Model() 
		{
			super(null);
 
		}
 
		public function change(x:Number, y:Number):void {
			this.x = x;
			this.y = y;
			super.dispatchEvent(new Event(Event.CHANGE));
		}
 
	}
 
}

И вьюшка:

package  
{
	import flash.display.Sprite;
	import flash.events.MouseEvent;
 
	public class Viewer extends Sprite
	{
 
		public function Viewer() 
		{
			super();
			init();
		}
 
		private function init():void
		{
			var someSprite:Sprite = new Sprite();
			someSprite.graphics.beginFill(0);
			someSprite.graphics.drawCircle(0, 0, 50);
			someSprite.graphics.endFill();
			super.addChild(someSprite);
			someSprite.addEventListener(MouseEvent.CLICK, super.dispatchEvent);
		}
 
 
		public function updatePositions(x:Number,y:Number):void {
			this.x = x;
			this.y = y;
		}
	}
 
}

По клику на кружок событие идёт в контроллер, оттуда просит модель изменить данные, модель данные меняет и говорит контроллеру, который обновляет вьюшку.

Возникает отсюда уже несколько вопросов:
1) Чтобы было совсем идеально-правильное MVC на твой взгляд, что нужно добавить, а что убрать?
2) Наверное, на столь простом примере не видно - но зачем такой полёт данных? Ведь если контроллер изменяет все данные, а моделька их всего лишь хранит - тогда, наверное, контроллеру уж точно видно что данные изменены и надо что то сказать вьюшке, зачем в моделе уведомлять об изменении?
3) А если я ф-цию change заменю 2-мя сеттерами, тогда я дважды вызову уведомление об обновлении, что плохо. Как быть?

Было бы очень здорово, если бы ты ткнул на конкретно этом примере, как сделать лучше.

[dimarik]

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

Вью - композитные. Похожи на дисплай лист.
Модель - тоже.
Контроллеры. Здесь особо не баловался, самостоятельно организовывал в виде команд. Но что-то мне подсказывает, что сделать иерархию контроллеров тоже можно.

[Psycho Tiger]

Да, спасибо, это мы уже всё разобрали =)
Почерпнул новое, однако же все вопросы выраженные постом раньше до сих пор остались нерешенными =(

[cpu]

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

[dimarik]

точно