Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   Статьи (http://www.flasher.ru/forum/forumdisplay.php?f=101)
-   -   Хорошее MVC (http://www.flasher.ru/forum/showthread.php?t=138349)

etc 07.04.2010 10:32

Цитата:

Сообщение от Psycho Tiger (Сообщение 898413)
1) Вот классы выше - теперь это правильное MVC?

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

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

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

Что касается «оригинальности», то достаточно картинки с Википедии:
http://upload.wikimedia.org/wikipedi...iagram.svg.png
Совершенно точно у View есть ссылка на модель.

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

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

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

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

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

Цитата:

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

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

cpu 07.04.2010 14:31

в model-и есть set-метод и get-метод.
Как сделать, что бы view НЕ мог работать с set-методом, но мог работать с get-методом? И при этом открыть доступ к обоим методам controller-у?

etc 07.04.2010 14:41

Цитата:

Сообщение от cpu (Сообщение 898640)
в model-и есть set-метод и get-метод.
Как сделать, что бы view НЕ мог работать с set-методом, но мог работать с get-методом? И при этом открыть доступ к обоим методам controller-у?

Указать в типе сеттера модели вьювера IModel, а не саму Model. В IModel описать доступные геттеры. Но вообще, это по сути защита от дурака.

cpu 07.04.2010 14:50

признаюсь: не знаю что такое IModel.
====================================================
Цитата:

Но вообще, это по сути защита от дурака.
- это я понимаю, так спрашиваю, на будущее.

Psycho Tiger 07.04.2010 15:08

IModel интерфейс, который имплементит Model.
Всем большое спасибо, особенно etc, уже понимаю суть.
Ещё 2 вопроса:
etc, а что нужно ещё поменять в той реализации что я дал, чтобы это ещё больше стало похоже на то, как написал бы ты? В голову лезет только добавление интерфейсов, и то что во втором вопросе.
Собственно второй вопрос: а есть ли какие то общие-базовые-классы для модели, вьюшки и контроллера? Тот же pureMVC - честно не понимаю, как MVC можно обернуть в фреймворк - наверняка там цепочка наследования controller -> controller base class -> object (или этих звеньев до object больше) и назревает вопрос - а какой функционал туда можно выносить? Голова не позволяет выделить что то общее, помимо сохранение ссылки на модель или вьюшку - но новый класс ради 2 строчек... как то бредово.

etc 07.04.2010 15:15

Цитата:

Сообщение от Psycho Tiger (Сообщение 898661)
etc, а что нужно ещё поменять в той реализации что я дал, чтобы это ещё больше стало похоже на то, как написал бы ты?

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

Цитата:

Сообщение от Psycho Tiger (Сообщение 898661)
Собственно второй вопрос: а есть ли какие то общие-базовые-классы для модели, вьюшки и контроллера? Тот же pureMVC - честно не понимаю, как MVC можно обернуть в фреймворк - наверняка там цепочка наследования controller -> controller base class -> object (или этих звеньев до object больше) и назревает вопрос - а какой функционал туда можно выносить? Голова не позволяет выделить что то общее, помимо сохранение ссылки на модель или вьюшку - но новый класс ради 2 строчек... как то бредово.

Можно каждому контроллеру создать свою модель. Можно в базовых классах модели организовать древовидность.

Psycho Tiger 07.04.2010 15:50

Цитата:

Добавить нужно в модель проверки на совпадение с текущими значениями, чтобы не слать событие лишний раз.
Совпадения значения сейчас? То в сеттере модели:
Код AS3:

if (currentValue==value) return;
currentValue=value;
super.dispatchEvent(...)?

Цитата:

Можно в базовых классах модели организовать древовидность.
О какой древовидности идёт речь? Не вижу закономерностей у 2 произвольных моделей или думаю не о том =(

etc 07.04.2010 19:10

Цитата:

Сообщение от Psycho Tiger (Сообщение 898674)
Совпадения значения сейчас? То в сеттере модели:
Код AS3:

if (currentValue==value) return;
currentValue=value;
super.dispatchEvent(...)?


Ну да, подобные проверки на текущее значение вообще в любом сеттере надо писать.

Цитата:

Сообщение от Psycho Tiger (Сообщение 898674)
О какой древовидности идёт речь? Не вижу закономерностей у 2 произвольных моделей или думаю не о том =(

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

Psycho Tiger 07.04.2010 20:27

Цитата:

Имеется ввиду структура данных, контейнер-список и конкретные элементы. Последние о родителе особо ничего не знают, но являются также элементами модели. Сама модель похожа на структуру DisplayObject-ов.
Ну да, это я понял, спасибо. Только мне не совсем ясна практическая ценность такого подхода. Какие плюсы?

etc 08.04.2010 09:44

Цитата:

Сообщение от Psycho Tiger (Сообщение 898750)
Ну да, это я понял, спасибо. Только мне не совсем ясна практическая ценность такого подхода. Какие плюсы?

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

Psycho Tiger 08.04.2010 19:47

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

Спасибо большое, теперь я разобрался. Наверное, в усвоении сейчас поможет только практика. Ещё раз огромное спасибо)

cpu 08.04.2010 23:01

Цитата:

Сообщение от cpu (Сообщение 898640)
в model-и есть set-метод и get-метод.
Как сделать, что бы view НЕ мог работать с set-методом, но мог работать с get-методом? И при этом открыть доступ к обоим методам controller-у?

ответил etc, что через интерфейс IModel.
=============================================
Если кому не лень, напишите в коде как это будет выглядеть.:rolleyes:

Psycho Tiger 08.04.2010 23:29

Код AS3:

package game 
{
        public interface ILandMovable
        {
                function get line():int;
        }
 
}


fljot 11.04.2010 13:14

А ещё часто пишут, что модель занимается бизнес-логикой.
Вот пример — видеоплеер. Заканчивается проигрывание видюшки, модель диспатчит соотв. событие. Кому лучше дальше принять решение проигрывать ли следующее/случайное видео из списка или остановится? На основании какого-нибудь mediaPlayer.config.repeatMode и mediaPlayer.config.shuffle ?

etc 11.04.2010 19:11

Цитата:

Сообщение от fljot (Сообщение 899578)
Кому лучше дальше принять решение проигрывать ли следующее/случайное видео из списка или остановится?

Контроллеру.

dimarik 13.04.2010 01:06

Цитата:

Сообщение от mexoboy (Сообщение 898587)
Тут собственно все описано: http://www.books.ru/shop/books/352130

Замечательная книжка. Только я не нашел там описание MVC в качестве паттерна. Дальнейшие рассуждения об "оригинальности" "паттерна" MVC считаю актом вероломства.

Psycho Tiger 13.04.2010 01:40

Кстати, вот сейчас интересный вопрос постиг:
Делаю игру, она 2.5д-шная, позиционирование объектов идёт как в 3д, но объекты являются уже отрисованными картинками и они просто поворачиваются нужным кадром к зрителю, создавая эффект 3д (короче, поворот на 360 кадрами мувиклипа, и крутим как будто бы в 3д). Странное чувство, но я уже даже не представляю, как это можно сделать без MVC... он чертовски заразный :D

Дак вопрос в чем - камера следует всегда за игроком и её можно крутить (только в одном направлении, конечно, иначе пререндер не имел бы смысла). В движке я переопределил методы поворота камеры с изменением модели PlayerModel (как никак это камера от игрока, поэтому туда засунуть считаю допустимым) и её же передаю другим объектам, которые должны крутится (чтобы они знали, когда нужно повернуться и куда). Это допустимо с точки зрения MVC, передавать не свою модель?

Котяра 13.04.2010 09:31

Если вид зависит от PlayerModel - то это его модель тоже. Вообще разделение на "своя" - "не своя" условно. Но на вашем месте я бы вынес данные о камере в Model.cameraData - для более читабельного кода. тогда CharacterView [i] следит за Model.characterData[i] и за Model.cameraData, что вполне логично.
Тут, кстати, пригодилась бы древовидная реализация модели с всплывающими событиями..

Tahion 13.04.2010 13:56

Цитата:

Сообщение от dimarik (Сообщение 900065)
Замечательная книжка. Только я не нашел там описание MVC в качестве паттерна. Дальнейшие рассуждения об "оригинальности" "паттерна" MVC считаю актом вероломства.

Да неплохая, она у меня даже есть :). Но вобщемто там многие патерны не описаны существующие)

Psycho Tiger 13.04.2010 15:56

Цитата:

Тут, кстати, пригодилась бы древовидная реализация модели с всплывающими событиями..
Можешь объяснить, что и куда? Я не понимаю, куда там дерево =\

Цитата:

Но на вашем месте
Давай на ты, вроде не первый день общаемся?

И да, у меня только один большой MVC, отвечающий за игрока и камеру, мелкие объекты вроде партиклов вообще идут одни классом, посложнее - а ля такие же юниты, как игроки - связкой V + MC. Может быть, это идиологически неправильно, но я руководствовался здравым смыслом.

Котяра 13.04.2010 18:17

При работе с партиклями, да и вообще с большим количеством объектов ( при z-сортировке например) mvc тоже не применяю - очень накладно. Лучше контроллером явно менять параметры видов.
Древовиная модель:
в твоем примере имеем что-то вроде:
Код AS3:

model {cameraModel{angleData,x,y},charModel1{data},charModel2{data}..,}

инициализация и подписка
Код AS3:

charView1.model = model
// тут уже можно по-разному организовать
model.addEventListener("Обновление_cameraModel",func);
model.addEventListener("Обновление_cameraModel_angleData",func);
model.cameraModel.addEventListener("Обновление__angleData",func);
 
model.charModel1.addEventListener("Обновление_data",func);
model.addEventListener("Обновление_charModel1_data",func);

события, соответственно, должны всплывать.

Psycho Tiger 13.04.2010 18:51

А зачем событиям всплывать?

etc 13.04.2010 19:25

Цитата:

Сообщение от Psycho Tiger (Сообщение 900259)
А зачем событиям всплывать?

Для удобства.
Вообще, под древовидной моделью я имел в виду не просто ссылки у родителя, а именно список детей и методы, схожие с методами DisplayObjectContainer.

Psycho Tiger 13.04.2010 19:52

Цитата:

Для удобства.
Гм, ну понятное дело что не в ущерб )
Я к тому что если есть подписка, например
Код AS3:

model.cameraModel.addEventListener("Обновление__angleData",func);

То зачем событию всплывать, чтобы его можно было поймать через
Код AS3:

model.addEventListener("Обновление__angleData",func);

Или я опять не о том?
Цитата:

Вообще, под древовидной моделью я имел в виду не просто ссылки у родителя, а именно список детей и методы, схожие с методами DisplayObjectContainer.
Гм, а я подумал о том, что предложил Котяра. Можно пример абстрактный тогда?

etc 13.04.2010 21:21

Цитата:

Сообщение от Psycho Tiger (Сообщение 900276)
Можно пример абстрактный тогда?

Код AS3:

var container:DataContainer = new DataContainer();
var data:Data = new Data();
container.addChild(data);
container.addChild(new MegaData());
container.addChild(new ItemData());


Psycho Tiger 13.04.2010 21:55

Да, это я понял, я немного о другом спрашиваю.
Ну вот отталкиваясь от примера, что ты мне написал:
Код AS3:

container.getDataAt(0)

В чем плюсы перед обычным объектом?
Код AS3:

var obj:Object={megaData: new MegaData()};

И почему была принята политика называть методы схоже с DisplayObjectContainer`ом?

etc 13.04.2010 22:06

Чтобы обеспечить зеркальность структуры вьюверов и модели.

Psycho Tiger 13.04.2010 22:14

Хм..
То есть примерно для таких нужд?
Код AS3:

var mc:SomeMovieClip=new SomeMovieClip();
mc.addChild(new OtherMovie());
(mc.getChildAt(0) as OtherMovie).model=bigModel.getModelAt(0);

Если да, то в голове пока что не укладывается удобство от такого "удобства".

etc 13.04.2010 22:21

Нет, имеется ввиду, что, например, вместе с событием REMOVED элемента модели удалится и вьювер, отображающий данный элемент. К примеру, в обычном List.

Psycho Tiger 13.04.2010 22:56

Ааа, и удалив модель земного шара мы удалим одним махом и модели всех землян вместе с вьюшками. Теперь стало понятно, спасибо )

etc 14.04.2010 17:16

Нет, я имел ввиду удаление одного землянина с земли одновременно с удалением оного из базы данных.

Котяра 15.04.2010 10:36

Цитата:

Сообщение от Psycho Tiger (Сообщение 900276)
То зачем событию всплывать, чтобы его можно было поймать через
Код AS3:

model.addEventListener("Обновление__angleData",func);

Или я опять не о том?

Я имел ввиду именно, то.
У меня тоже древовидная структуру, только в отличии от etc - я не делал аналог DisplayObject с addChild и.т.п.
У меня просто в конструкторе модели - передаётся ссылка на парент (которую, в принципе можно и сменить потом, но мне пока ни разу не понадобилось.)

Код AS3:

 model.submodel = new Submodel(model);
// вернее чаще так
в классе модели:
submodel = new Submodel(this);

причём основную модель я пару-раз делал ребёнком контроллера - тогда все события модели доходят до контроллера всплытием.
пример : слушаем смерть землянина:
в контроллере
Код AS3:

model.addUpdateFieldListener(HumanModelField.IS_DEAD,removeHuman);
 
public function removeHuman(e:ModelEvent)
{
var deadHumanModel:HumanModel = e.target as HumanModel;
var isDead :Boolean= e.field;
if(isDead )
{
//удаляем подмодель  из модели
// удаляем вид связанный с моделью
// прочеее
}
}

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

etc 15.04.2010 10:40

currentTarget? Ты уверен? :)

Котяра 15.04.2010 11:07

Цитата:

Сообщение от etc (Сообщение 900663)
currentTarget? Ты уверен? :)

блин, скосячил - target конечно..)

Psycho Tiger 15.04.2010 18:18

Цитата:

т.е. тут контроллеру не надо подписывать на события модели каждого человека. он просто слушает все сообщения о смерти)
Ааа... всё, теперь всё стало понятней) Только вот:
Код AS3:

var isDead :Boolean= e.field;

Ты посылаешь в событии то что нужно узнать обработчику?
И вот тут:
Код AS3:

model.addUpdateFieldListener(HumanModelField.IS_DEAD,removeHuman);

покажи код метода addUpdateFieldListener, не очень ясно почему не просто addEventListener )

Котяра 16.04.2010 09:42

тут у меня "не очень" ООП-ный код используется..
ModelEvent имеет свойство field:*
Цитата:

addUpdateFieldListener===addChangeModelFieldListener
переименовал,а вообще можно field и не использовать.
Код AS3:

public function removeHuman(e:ModelEvent)
{
var deadHumanModel:HumanModel = e.target as HumanModel;
var isDead :Boolean= deadHumanModel.isDead;
if(isDead )
{
...


Psycho Tiger 16.04.2010 16:34

Угу, мне вот второй способ кажется логичней. Лучше спросить кому надо, чем знать это всем.
А вот это зачем? Для какой цели?
Код AS3:

_modelFieldEventListenersArray.push( { event:ModelEvent.CHANGE + field, listener:listener,scope:scope } );


Котяра 16.04.2010 16:58

это регистрация для автоматического удаления всех листенеров

Psycho Tiger 16.04.2010 20:36

Понял. Спасибо за разъяснения.

dimarik 20.04.2010 00:25

Цитата:

Сообщение от Tahion (Сообщение 900175)
Да неплохая, она у меня даже есть :). Но вобщемто там многие патерны не описаны существующие)

Например?

Добавлено через 5 минут
Цитата:

Сообщение от Котяра (Сообщение 900662)
У меня тоже древовидная структуру, только в отличии от etc - я не делал аналог DisplayObject с addChild и.т.п.
У меня просто в конструкторе модели - передаётся ссылка на парент (которую, в принципе можно и сменить потом, но мне пока ни разу не понадобилось.)

Стандартный GOF-паттерн Composite. Что у тебя, что у Дениса, точнее, у Блуда.

Добавлено через 11 минут
Цитата:

Сообщение от Котяра (Сообщение 900662)
причём основную модель я пару-раз делал ребёнком контроллера - тогда все события модели доходят до контроллера всплытием.

А я видел фильм с Арнольдом Шварценеггером, "Total Recall". И мне понравилась тетя с тремя сисями. Ну хоть и не по-человечески, а то и приятно ).

Добавлено через 18 минут
Цитата:

Сообщение от Котяра (Сообщение 900662)
Код AS3:

model.addUpdateFieldListener(HumanModelField.IS_DEAD,removeHuman);


Откуда такая ненависть к абстракции? В продукте лучше не упоминать о "concrete product" всуе. Здесь подойдет какой-нибудь Event.COMPLETE, вместо ХУМАНМОДЕЛ.МЕРТВ.

Я уж молчу о нововведении "addUpdateFieldListener". Чем EventDispatcher не угодил? Не следует множить сущее без необходимости.


Часовой пояс GMT +4, время: 03:54.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.