Хорошее MVC

[Ariel]

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

[cpu]

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

[etc]

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

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

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

[cpu]

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

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

ответил etc, что через интерфейс 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-ов.

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