Хорошее MVC

[etc]

Сообщение от 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`ом, а не через геттеры от модели о нужной информации?

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

[cpu]

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

[etc]

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

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

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

[cpu]

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

Но вообще, это по сути защита от дурака.

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

[Psycho Tiger]

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

[etc]

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

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

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

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

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

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

[Psycho Tiger]

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

Совпадения значения сейчас? То в сеттере модели:

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

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

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

[etc]

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

Совпадения значения сейчас? То в сеттере модели:

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

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

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

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

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

[Psycho Tiger]

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

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

[etc]

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

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

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