fish_r, ты действительно не сказал ничего, что оспаривал бы Dukobpa3. Особенно легко в этом убедиться, прочитав пропущенный тобой комментарий прямо над твоим возражением.
Вы об одном и том же разными словами :)

Я его и не пропустил. Мы обсуждали другую частность:

Ясно. И как это
противоречит этому
Координаты юнита на карте разумеется должны храниться/изменяться в модели (вы оба придерживаетесь схемы, где модель — это данные и логика по их обработке). Вьюха может быть чем угодно (2D, 3D, забавным мультиком, диаграммой посещаемости "храма" юнитами за отчетный период, и т.д.). И модели до этого нет никакого дела. Она живет своей жизнью.

А вот это действительно лишнее:

Вот это вот действительно лишнее.

Хорошо. Предположим вы делаете не игру, а польз. интерфейс заносите ли вы координаты кнопок в модель?

Ну и на этот вопрос тебе Dukobpa3 уже давал ответ, с которым я согласен
Юнит — не кнопка. Юнит — фигурант логики приложения. Кнопка — кликабельный кусок монитора.

@Zebestov - Спасибо, наверное))) Мои слова поняты верно и с первого раза, плюс за поддержку.

@fish_r - Слушай что тебе старшие говорят ;-Р

Интересует взаимосвязь модели с вью. Вьюшка не может изменять модель. Но у нее есть ссылка на модель, соответственно... сами понимаете что. Акцессоры здесь не подходят, так как контроллер должен изменять те же свойства, которые читает вью. В отдельный пакет вьюшку тоже не закинешь. Понятно, я не собираюсь в представлении как-то менять модель :). Но интересно на будущее, просто чтобы уж "совсем правильно", как здесь быть?
Если создать событийный класс для событий модели (имею в виду "пользовательское событие" по К.Муку). В этот класс при диспатче из модели передавать все доступные параметры для вьюшки. Это будет правильно?

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

Не правильно. Вьюшка просто услышит про изменения и сама пойдет к модели выяснять, что там поменялось. Ей даже не важно, кто и каким образом поменял эти значения (модель сама там что-то насчитала, контроллер что-то там вызвал, с сервера данные подоспели).

да

Как вариант прокатит, и даже более того это будет один из самых правильных вариантов но сложен в реализации. Сложно будет сделать адекватный рендер с обработкой всех событий и слишком легко запутаться.

Очень даже подходят. Просто вью ничего не меняет в модели, только читает всё что ей нужно. А контроллер может еще и менять. Технически это разделить сложно, хотя можно, там придется неймспейсы прикручивать. Я на практике просто сам сознательно не трогаю модель из вью и всё.

Т.е. получается модель продиспатчила - меня изменили. Вью полезла посмотрела нужные данные и всё.

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

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

Добавлено через 8 минут
А вот это действительно несущественно. У вьюхи есть ее модель и ее основная задача с одной стороны отображать во внятном а не абстрактно-циферном виде состояние этой самой модели, чтоб пользователю понятно было. А с другой стороны передавать действия пользователя контроллеру чтобы тот мог принимать какие-то решения или давать модели команды.

Это понятно. Я же не говорю что она должна знать кто что менял. Жаль что не правильно. Яхотел просто вьюшку подписать на события модели и больше модель в ней вообще не трогать. Что-то типа этого: То есть, чтобы за свойством activeUnit не лезть в модель с которой по-пьяни можно сделать что-то, а получить его прямо из событийного обьекта ModelEvent.
Что же, будем делать "правильно". Спасибо :)

Добавлено через 8 минут
Не совсем понял. У меня какбэ все просто. Есть класс ModelEvent, на события которого подписываются две вьюшки, вернее одна вью - и компьютер(АI). Они получают такие события от модели. Отправляют в контроллер события OpponentEvent.