Хорошее MVC

[Psycho Tiger]

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

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

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

[mexoboy]

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

cpu
1) view имеет ссылку на модель;
2) Контроллер на них обоих;
3) Модель отправляет события вьюверу. Вьювер — контроллеру.

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

[cpu]

mexoboy +1

[dimarik]

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

2ЦПУ; 2ДИМАРИК ::
"точно" ни разу не точно. Это только одна из реализаций, причем не самая чистая. Мука почитать (и на ВИКИ посмотреть) так выходит, что все данные+логика тройки - в модель. Это будет классическая имплементация MVC. И ходят оне парами как M+VC, т.е. при замене Вью меняем и Контроллер к нему. На эти темы уже копий переломано!...

Привет! Ваш пост номер 13 и Вы выиграли поездку в кАННЫ на очередной фестиваль КО)
По сути. ТОЧНО есть точно.

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

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

1. View не имеет ссылок никуда, только рассылает события в контроллер

Просто рассылает события. Когда Вы кричите "Пожар!!", адресуете любому слышащему.

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

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

А вообще я последнее время сильно охладел к MVC - как к универсальному решению) выхожу из стадии abstraction freek)

Для тебя уже поздно ) Ты заражён MVC.

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

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

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

А мы дадим ей только читать )

[Psycho Tiger]

А мы дадим ей только читать )

Ну да, спасибо, это один из самых малозначимых вопросов на данный момент =)

Подписываюсь к вопросу о том, что нужно ли вьюшке иметь ссылку на модель и если нет - как получать данные об обновлении.

[dimarik]

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

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

Расскажите нам об оригинальном паттерне, пожалуйста.

Добавлено через 44 секунды

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

Ну да, спасибо, это один из самых малозначимых вопросов на данный момент =)

Подписываюсь к вопросу о том, что нужно ли вьюшке иметь ссылку на модель и если нет - как получать данные об обновлении.

Одназначна (с).

[Ariel]

Гр-н Димарик реально радует своими ч0ткими и однозначными ответами.
P.S. Поездку в Канны присылайте пожалуйста по электрической почте.

[Котяра]

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

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

вот эти вопросы самые сложные ( во всяком случае для меня)
в своеё реализации mvc я диспатчил события для изменения любого отдельного свойства
подписывался также.
вот пример из рабочего проекта ( 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);
		}
 
 
	}
 
}

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

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

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

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

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

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

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

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

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

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

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

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

[etc]

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

Но ведь тогда view может напрямую менять данные в модели обойдя controller

Может, только это не в его компетенции.

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

Так как View имеет ссылку на модель, он может получит по этому событию данные из model для отображения, обойдя contoller(который опять неудел.)

Ещё раз: может ещё не означает, что так и должен делать. Вы можете дома открыть газ в плите и зажечь спичку через пару-тройку минут, но почему-то этого не делаете.

[mexoboy]

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

Расскажите нам об оригинальном паттерне, пожалуйста.

Тут собственно все описано: http://www.books.ru/shop/books/352130