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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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