Хорошее MVC

Psycho Tiger · 06.04.2010, 16:43

Цель MVC - отделить то, что на экране от того, что происходит логикой. Короче, если проект расчитывался как консольный, а потом вдруг трах тибидох и хотим 3д - надо будет менять лишь вьюшку.

Главный класс:

Код AS3:

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

Контроллер:

Код AS3:

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(_model);
		private var _container:DisplayObjectContainer;
		public function Controller(container:DisplayObjectContainer) 
		{
			_container = container;
			init();
		}
 
		private function init():void
		{
			_container.addChild(_viewer);
			_viewer.addEventListener(MouseEvent.CLICK, onViewerClick);
 
		}
 
		private function onViewerClick(e:MouseEvent):void 
		{
			_model.change(Math.random() * 400, Math.random() * 400);
		}
 
 
	}
 
}

Модель:

Код AS3:

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));
		}
 
	}
 
}

Вьюшка:

Код AS3:

package  
{
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
 
	public class Viewer extends Sprite
	{
		private var _model:Model;
		public function Viewer(model:Model) 
		{
			super();
			_model = model;
			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);
 
			_model.addEventListener(Event.CHANGE, onModelChange);
		}
 
		private function onModelChange(e:Event):void 
		{
			super.x = _model.x;
			super.y = _model.y;
		}
 
 
 
		public function get model():Model { return _model; }
 
		public function set model(value:Model):void 
		{
			_model = value;
		}
	}
 
}

И серия вопросов вновь

Спасибо, что помогаешь.
1) Вот классы выше - теперь это правильное MVC?
2) Да, действительно - вьюшка может менять что нибудь у модели и контроллер сойдёт с ума - получается, у этой триады даже пиша вьюшку надо быть аккуратным, потому что можешь всё сломать?
3) А кто от кого наследуется? Я так понимаю: controller -> Object, model - EventDispatcher, viewer - DisplayObject. Так?
4) Модельку передавать в конструктор вьюшки это хорошая практика, или всё таки лучше через сеттер? (вопрос граничит с бредом, знаю

)
5) На той же википедии и на некоторых других сайтах пишут, что контроллер - лишь связующее, а вся бизнес логика в модели. Они не правы или с флешем тонкость какая?
6) Склоняюсь к мнению, что чистый MVC не в гигантских проектах нафиг не нужен, хотя мне нравится идея о MC + V. Такое существует вообще, контроллер с интегрированой моделью? Если да, то как там поступаем? Если контроллер уже имеет прямую ссылку на вьюшку, а в нём же интегрированна модель - то смысла в событии нет, можно отправлять напрямую или же ради сохранения полиморфизма и перехода после к чистой MVC следует остановится на событиях?

Котяра · 06.04.2010, 17:52

Цитата:

Сообщение от Psycho Tiger

2) Да, действительно - вьюшка может менять что нибудь у модели и контроллер сойдёт с ума - получается, у этой триады даже пиша вьюшку надо быть аккуратным, потому что можешь всё сломать?

передавать в вид только IModel в котором, например,есть один только метод addChangeModelEventListener
сломать конечно можно но это будет уже очень явно.

Psycho Tiger · 06.04.2010, 17:59

Цитата:

Сообщение от Котяра

передавать в вид только IModel в котором, например,есть один только метод addChangeModelEventListener
сломать конечно можно но это будет уже очень явно.

Конечно, сломать можно всё делая это специально - когда говорил "сломать" подразумевалось конечно же "ненароком менял вьюшку, а полетела всё остальное".
С этим появляется ещё 2 вопроса:
7) Насколько это хорошая практика - делать по 40 разных событий для 40 изменений - то есть, если изменился угол поворота чей нибудь - не обновлять положение в пространстве, а лишь повернуть (то есть разбиение например updatePositionEvent на updateXYPositionEvent и updateRotationEvent)
8) Если передается только интерфейс, тогда вся инфа об обновлении должна поступить вместе с Event`ом, а не через геттеры от модели о нужной информации?

Котяра · 07.04.2010, 09:56

Цитата:

Сообщение от Psycho Tiger

Конечно, сломать можно всё делая это специально - когда говорил "сломать" подразумевалось конечно же "ненароком менял вьюшку, а полетела всё остальное".
С этим появляется ещё 2 вопроса:
7) Насколько это хорошая практика - делать по 40 разных событий для 40 изменений - то есть, если изменился угол поворота чей нибудь - не обновлять положение в пространстве, а лишь повернуть (то есть разбиение например updatePositionEvent на updateXYPositionEvent и updateRotationEvent)
8) Если передается только интерфейс, тогда вся инфа об обновлении должна поступить вместе с Event`ом, а не через геттеры от модели о нужной информации?

вот эти вопросы самые сложные ( во всяком случае для меня)
в своеё реализации mvc я диспатчил события для изменения любого отдельного свойства
подписывался также.
вот пример из рабочего проекта ( as2)

Код AS1/AS2:

class ru.k0t0vich.mvc.models.Model extends EventDispatcher
{
 
	public function Model(eventParentLink) 
	{
		eventParent = eventParentLink;
	}
 
	/**
	 *  Диспатчим событие об изменении структуры
	 * @param	field - имя поля (должно присутьствовать в  классе, иначе генерируется ошибка времени выполнения)
	 */
	public function update(field:String):Void
	{
		if (field == undefined) field = "";
		var event: ModelEvent= new ModelEvent(ModelEvent.CHANGE+field);
		// Проверка на доступность свойства
		if (field != "")
		{
			try
			{
			event.field = this[field];
			}
			catch (e:Error)
			{
				trace (e);
			}
			dispatchEvent(event);
		}
		else
		{
			event.field = this;
			dispatchEvent(event);
		}
 
 
	}
 
}

подписка во вью:

Код AS1/AS2:

		public function addChangeModelFieldListener(field:String,listener:Function,scope:Object):Void
		{
			_model.addEventListener(ModelEvent.CHANGE + field, listener,scope);
                        // регистрируем для отписки от ВСЕХ событий модели
			_modelFieldEventListenersArray.push( { event:ModelEvent.CHANGE + field, listener:listener,scope:scope } );
		}

пример подписки:

Код AS1/AS2:

	/**
	 * Инициализацие хэндлеров изменения модели
	 */
	private function initModelListeners()
	{
		addChangeModelFieldListener(SlotModelField.LINES, showLinesByModel, this);
		addChangeModelFieldListener(SlotModelField.FREESPINS, updateFreespinsCounter, this);
		addChangeModelFieldListener(SlotModelField.WIN, updateFreespinsCounter, this);
	}

косяков в такой реализации много ( нет строгой типизации итп) но многое лечится вводом класса констант SlotModelField. доступ к геттерам модели у меня кстати тоже так сделан,

Код AS1/AS2:

private function updateFreespinsCounter(e:ModelEvent):Void
	{
		freespinsCounterWindow.freespins = model[SlotModelField.FREESPINS];
		freespinsCounterWindow.cash = model[SlotModelField.WIN];
	}

хотя можно сделать в IModel геттеры этих свойств - я не сделал т.к. при добавлении публичных обновляемых свойств в модели пришлось бы редактировать уже 3 класса ( Model, ModelField и IModel) а не 2 (Model, ModelField)

модель обновляется таким образом:

Код AS1/AS2:

	public function get totalBet():Number { return _totalBet; }
 
	public function set totalBet(value:Number):Void 
	{
		_totalBet = value;		
		update(SlotModelField.TOTAL_BET);
	}

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

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

Код AS3:

         public function update(field:String):Void
	{
		if (field == undefined) field = "";
		var event: ModelEvent= new ModelEvent(ModelEvent.CHANGE+field);
		dispatchEvent(event);
 
	}

etc · 07.04.2010, 10:32

Цитата:

Сообщение от Psycho Tiger

1) Вот классы выше - теперь это правильное MVC?

В целом на то, как это делал бы я, уже похоже.

Цитата:

Сообщение от Psycho Tiger

2) Да, действительно - вьюшка может менять что нибудь у модели и контроллер сойдёт с ума - получается, у этой триады даже пиша вьюшку надо быть аккуратным, потому что можешь всё сломать?

Оно, конечно, может менять модель, но опять же, если вам приспичило спрыгнуть с балкона, он вам не сможет помешать.

Цитата:

Сообщение от Psycho Tiger

3) А кто от кого наследуется? Я так понимаю: controller -> Object, model - EventDispatcher, viewer - DisplayObject. Так?

Чаще всего — да. Но и контроллер тоже может события рассылать.

Цитата:

Сообщение от Psycho Tiger

4) Модельку передавать в конструктор вьюшки это хорошая практика, или всё таки лучше через сеттер? (вопрос граничит с бредом, знаю

)

Это зависит от задачи, если планируется переиспользование вьювера для отображения различных данных, то сеттер предпочтительнее.

Цитата:

Сообщение от Psycho Tiger

5) На той же википедии и на некоторых других сайтах пишут, что контроллер - лишь связующее, а вся бизнес логика в модели. Они не правы или с флешем тонкость какая?

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

Добавлено через 8 минут

Цитата:

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

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

Что касается «оригинальности», то достаточно картинки с Википедии:

Совершенно точно у View есть ссылка на модель.

У модели нет конкретной ссылки на представление. Ссылка на уровне приложения конечно есть, но она лишь на уровне подписчика на изменения, поэтому и выполнена пунктиром.

Выполнять обязанности прокси контроллеру незачем, потому как для множества вьюверов писать множество прокси-методов — бессмысленное нагромождение ненужного кода в контроллере. А если у вас будет ещё и иерархическая модель, то количество таких ненужных проксей для каждого элемента модели вырастет в геометрической прогрессии.

Добавлено через 10 минут

Цитата:

Сообщение от Psycho Tiger

7) Насколько это хорошая практика - делать по 40 разных событий для 40 изменений - то есть, если изменился угол поворота чей нибудь - не обновлять положение в пространстве, а лишь повернуть (то есть разбиение например updatePositionEvent на updateXYPositionEvent и updateRotationEvent)

Я предлагаю исходить из здравого смысла. Если изменения одного рода, то не смысла для каждого из них делать своё событие.

Цитата:

Сообщение от Psycho Tiger

8) Если передается только интерфейс, тогда вся инфа об обновлении должна поступить вместе с Event`ом, а не через геттеры от модели о нужной информации?

А что мешает описать геттеры и в интерфейсе? Менять не можем, а читать вполне себе да.

cr0w312 · 01.03.2011, 16:47

Цитата:

Сообщение от Psycho Tiger

Цель MVC - отделить то, что на экране от того, что происходит логикой. Короче, если проект расчитывался как консольный, а потом вдруг трах тибидох и хотим 3д - надо будет менять лишь вьюшку.

если в контроллере происходит расчет коллизий, а мы вдруг трах тибидох и 3d, контроллер тоже надо будет менять, так как в расчете столкновений появляется z координата, и модель наверно тоже надо будет дополнить?
если я туплю не пинайте сильно, модель может состоять из 5-7 классов?

Bgg · 01.03.2011, 16:58

Цитата:

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

если в контроллере происходит расчет коллизий, а мы вдруг трах тибидох и 3d, контроллер тоже надо будет менять, так как в расчете столкновений появляется z координата, и модель наверно тоже надо будет дополнить?
если я туплю не пинайте сильно, модель может состоять из 5-7 классов?

Столкновения визуальных объектов должен рассчитывать View, и результат(столкнулся/не столкнулся) отдавать контроллеру.

terbooter · 01.03.2011, 17:10

Цитата:

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

Столкновения визуальных объектов должен рассчитывать View, и результат(столкнулся/не столкнулся) отдавать контроллеру.

Очень спорное утверждение

cr0w312 · 01.03.2011, 17:16

Цитата:

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

Столкновения визуальных объектов должен рассчитывать View, и результат(столкнулся/не столкнулся) отдавать контроллеру.

у меня 10 вьюшек которые ничего друг о друге не знают. у них есть модели, а у контроллера есть и модели и вьюхи

Psycho Tiger · 01.03.2011, 17:29

Цитата:

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

Столкновения визуальных объектов должен рассчитывать View, и результат(столкнулся/не столкнулся) отдавать контроллеру.

Минус. Столкновение — это логика.