Вопрос спорный, как видно из разных источников. Мне ближе реализация логики в модели, которая кому-то что-то выдает "на показать" (методы для View), от кого-то принимает инструкции "на поменять" (методы для Controller), и вещает в эфир об изменениях (для View, для родителя). А кто эти люди — не ее солдатское дело =)
Пока все стройно.

Согласен — не так выразился. Модель предоставляет публичные методы, контроллер их вызывает.

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

Psycho Tiger, я сейчас переключился на игрострой, так что потренируюсь "на кошках" и проверю в бою свою позицию.
А соц. проект до поры отложен, так что тут пока ничего не отвечу, чтобы не балаболить. Может ты и прав — надо пробовать.

да. мс вообще сложно разделить иногда. но в моих реализациях - моджель - это только данные и диспетчер изменений. всё. изменяет данные только контроллер. читать данные может виды и контроллер.
плохо что нельзя разделить доступы для геттеров и сеттеров модели, только через нэймспэйсы или интерфейсы, но это очень не удобно.
приходится в модели реализовывать по 2-м интерфейсам
IМodelReadable (только геттеры) и IModel (геттеры и сеттеры)
первый - для видов - второй для контроллеров. можно забить, но не кошерно..

Котярка, а зачем и геттеры и сеттеры? Только для контроллера, а он может иметь полный доступ, т.е. без интерфейсов. Ну это имо )

Psycho Tiger, а как же View! Для него read-only интерфейс полезен.

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

View да. Но Котяра говорил про 2 интерфейса - один для контроллера и я подметил, что в большинстве случаев он лишний.

2Тигра -да насчёт интерфейса для контроллера ты частично прав. контроллер имеет полный доступ, но мне приходилось делать Action ( в соседней теме обсуждается), которые являются частью контроллера, т.е. могу т изменять модель - им в качестве праметра передавались частичные интерфейсы IModel.
например в контроллере у меня встречатся такой код:
ChangeStatusAction - может использоваться в другом контроллере, он например проверяет некие флаги доступные в IStatusModel и меняет поле status у модели..
всё это очень частный случай, просто у меня есть больше 100 независимых казиношных игр с более-менее общим кодом (всё лежит в одном пакете кода), общая механика может быть похожей, но в некоторых нюансах отличаться.. поэтому приходиться быть очень гибким чтобы не использовать копипасту, а использовать ООП.

Угумс, согласен.
Знаю, что код выдернут из контекста но... ты вроде ведь не пишешь this и super?

код написал прям здесь - this не пишу, это для здесь - как указание, что это метод контроллера

Котяра, на мой взгляд тоже: с двумя интерфейсами - перебор. Вот можно сделать так (через нэймспейсы):
Model.as
А в контроллере, для примера, что-то вроде:
В getNsSetter( controller:IController ) - IController для примера. Можно и не для контроллера сделать.

Или вообще переменной _myProperty назначить не protected, а сразу _nsSetter нэймспейс. А сеттер myProperty и вовсе убрать. Тогда в контроллере нужно будет работать через неймспейс с переменной, а в остальных классах - только с геттером.

Растолкуйте ситуцию с главными и подчиненными контроллерами. Полагаю, что главный агрегирует подчиненный. Как у них общение налажено? Особенно интересует от подчиненного к главному.

У подчиненного есть ссылка на базовый.

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

полная каша. почитайте сначала топик с начала и вдумчиво.

Думаю статейку накатать на днях про MVC для нубов вот...

нубы будут очень благодарны! и еще бы с примером какимто простым

Лучше с непростым. С простым там всегда все просто и понятно. Так что нужно с жизненным :-)

От простого - к сложному. Думаю на днях накалякаю. Хочу с картинками )

Это общий дуализм GOF-паттерна Observer. По моему мнению, разработчику необходимо решить какое количество информации необходимо нести в конкретном событии. Можно ввести отдельное событие для каждого изменения модели. Можно ввести одно событие для любого изменения модели. Представление может запросить у модели (POP-операция) недостающие в событии данные. Событие может нести в представление избыточное количество информации (PUSH-система). Истина где-то рядом.

да, да, скорее бы )))

Народ, а есть ли смысл использовать mvc для простых проектов, например, для создания flv плеера? Если смысла нет, может можно применить просто C+V?

паттерны были придуманы для больших / сложных проектов. Если ваш плеер будет описан парой сотен строк кода, то использование mvc, на мой взгляд, неоправдано.

Я кстати, её уже пишу.

MVC всегда есть смысл использовать, ровно как всегда есть смысл его не использовать.

Паттерны бывают разные, и не все они только для больших и сложных проектов (и уж тем более не для них придуманы ;) ).
Если flv плеер планируется усовершенствовать и наращивать функционал (обычно так и бывает), то лучше изначально об этом подумать.

Именно это я и хотел сказать. Спасибо )

Ну я про то же, моя цитата - обоснование использования readOnly интерфейса модели.
В случаях, когда вид должен читать данные модели (POP) - ссылка на модель должна передаваться виду как readOnly интерфейс.

Вот вы говорите про pop и push от вьюхи в модель. Речь идёт о стэке? Разве это нормально что вьюшка так или иначе меняет модель?

Не, это не о том..
Pop Pull - система оповещения - берём данные самостоятельно.
Push - посылаем вместе с событием.
вот тут на примере java

угу, планируется, именно поэтому я и задумался о mvc

А, всё, понял. Пример даже излишен, объяснения хватает заглаза ) Спасибо.
Только вот:
Всё таки pop или pull?

Ошибся. Правильно pull. Спасибо что поправили.

ребят, пытаюсь повернуть мозги в сторону MVC, накидал кое-какой примерчик.
чего хотел - сделать возможность на ходу менять вьюшки деталей робота без особого вреда для здоровья (setter/getter). наказякал по этому случаю класс Robot.
вопрос - насколько тут все криво?

сорсы
пощупать

cleptoman:
1. На мой взгляд стоит класс Robot сделать вьюшкой-наследником Sprite, а управление с изменением модели выделить из Main (WASD) и Robot(мышка О_о) в отдельный класс-контроллер. А то у вас получается что Robot выполняет функции и представления, и контроллера.

2. Не уверен что параметр moving в TracksModel - настолько важная информация, чтобы хранить ее в модели.

3. Ну и SPEED лучше хранить в модели (RobotModel или TracksModel)

спасибо, буду дальше репу морщить.

Назрел такой вопрос.
Кто создает контроллеры?

Рутовый класс создает главный контроллер, который создает модель (у меня модель создается полностью) и вьюшку (отдельные элементы у меня создаются по необходимости)
Модель не имеет ссылок ни на контроллеры ни на вьюшку, только диспатчит сигналы
Вьюшка получает ссылку на модель и строится по паттерну компановщик.

Инстанцировать контроллер во вьюшке нельзя, тк 1) контроллер нужно инициализовать (передать ссылки на необходимые сабжекты), 2) неправильный расход ресурсов.

Значит ссылки на необходимые контроллеры должны передаваться при инициализации вьюшки.

Вопрос. Где и как создавать контроллеры?

Контроллеры.
Вполне нормально )
Аха.
Необязательно. Вьюшка строится по паттерну Composite только из за того, что так устроен ФП (компоновщик = Composite? Я перевод плохо знаю )), а так MVC по бОльшему счету привязан только к обсерверу.
Вьюшка - отображает. У неё едва мозгов на это хватает, куда ей контроллеры? )
У вьюшки только одна ссылка - на модель.
В контроллерах. Контроллер создаёт модель и вьюшку. А может создать ещё один контроллер, который тоже создаст и модель, и вьюшку. Чаще всего он же передаёт младшему контроллеру ссылку на себя - чтобы тот мог подёргать у него некоторые методы)

Наконец-то осилил... Нафлудили мама не горюй:)

С простейшим примером вроде разобрался.

1. Есть главнй класс приложения.
2. Он создает главный контроллер себя отдает этому контроллеру ссылкой в качестве контейнера вьюх
3. Главный контроллер делает главную вьюху и пихает ее в этот контейнер
4. Главный контроллер делает главную модель (главная модель по сути хранит в себе текущий стейт и знает какое сейчас окно открыто + игровая доп-инфа по типу - сколько уровней пройдено, какой уровень следующий и т.п.)
//********************
после этих действий можно считать что мы стартонули.

Далее
0. У главной модели есть какой-то стейт по-умолчанию (майн-меню к примеру)
1. Главный контроллер глядит что у нас там в модели за стейт, в зависимости от этого создает триаду нужного экрана (майн меню, игровой экран, хайскоры, etc). Вьюху от этой триады засовывает в подчинение главной вьюхе, сам же подписывается на контроллер окна.
2. Вьюха этого окна диспатчит события на действия пользователя, события эти получает и обрабатывает контроллер окна.
3. Как только контроллер окна получает от вьюхи событие ченж_стейт - он диспатчит его дальше.
4. Ченж_стейт от контроллера окна получает главный контроллер. В ответ на это событие он зашибает эту триаду окна и создает другие (например были в главном меню и перешли в окно хайскоров, зашибли майнменю, и создали триаду хайскоров)
//*******************
Так, собственно с логикой Главного контроллера вроде разобрались. Он у нас такой типа крутой, по мелочам не разменивается и решает только глобальные вопросы (в данном примере только ченж_стейт)

Если я тут нигде не протупил - то поидее всё понятно, если же протупил то поправьте. А вопросы у меня дальше.

А теперь собственно самое интересное.
Мы заходим в игровой экран. А тут всё интересно. Возьмем по минимуму:
Делаем тавердефенс. Три вида башен. Пять видов врагов. Три уровня. Всё.

1. После того как главный контроллер получает событие смены стейта на игровой экран он убивает текущий экран и создает игровой (он в момент смены стейта уже знает какой уровень надо открыть, заранее запрашивая себе "правильную модель" с сервера или из файла или откуда там надо.)
2. Получает он данные из этого некого места, пихает их в свежесозданную модель. Прикручивает к ней ее персональный контроллер. Создает по этой модели вьюху и пихает эту вьюху в главную вьюху.
(получается с такой структурой задачей основного класса является только стартонуть это всё а потом быть контейнером для главной вьюхи. Главная вьюха является родительской для всех остальных.)

Тут пока вопросов вроде нету. Мы просто взяли и нарисовали уровень по той же схеме что и остальные окна.

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

1. По клику на "Создать башню №1" - вьюха уровня диспатчит событие "Создать башню"
2. Ее слышит контроллер уровня.
3. В ответ он создает триаду новой инстанции башни. Вьюху кидает внутрь вьюхи уровня. Модель хранит у себя. Контроллеру башни позволяет заниматься логикой башни(ну к примеру в контроллере башни всякие там таймеры и тригеры типа раз в 1 сек перезарядка, а если враг ближе чем 50 пкс - то стрелять)
3.1. ну и дальше башня живет своей жизнью.
3.2. Контроллеру уровня на башню пофигу пока она(либо ее модель, если обнаружит что хп==0; либо вьюха, если юзер тыкнет в кнопку "под снос") не задиспатчит что-то типа "Меня поламали".
3.3. Но на всякий случай контроллер уровня башню слушает, потому что может быть получено какое-то событие типа "на меня навели мышкой" при этом контроллер уровня должен отобразить над башенкой окошко с доп-инфой (или этот функционал висит на контроллере + вью башни? Если так то схема получается следующая - вьюха понимает что на нее навели мышью, никуда ничего не диспатчит и сама на себе выводит окошко инфы.)
4. когда контроллер уровня получает от башни заветное "Меня поламали" - он сносит триаду этой башни. Если надо, вносит в какой-то реестр разбитых башен - т.е. в модель уровня. Ну малоли, хайскоры от этого будут зависеть или еще чего.

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

//**********************
Вот примерно так я себе это вижу.

А теперь вопорсы:
1. Что-то мне подсказывает что я слишком наворотил со вьюхами. В чем роль этого контейнера вьюх? А то у меня получилось что этот контейнер вьюх держит в себе только одну вьюху - главную. Тут короче где-то дублирование. Или я суть главной вьюхи не уловил, или же суть главного класса.
2. Ну и вот это всплывающее окошко - кто его показать должен? Вьюха башни или вьюха уровня? Насколько я понимаю то вьюха башни это какой-то спрайт или Мувик с анимацией самой башни. Стоит себе, привязана к координатам. Ну а чтоб это окошко выглядело так как охота чтоб оно выглядело - то надо его показывать в дисплейОбъекте уровня (ну чтоб за мышкой двигалось и в таком духе).
2.1. Хотя как вариант можно сделать отдельную триаду для хинтов. Триада эта будет на том же уровне что и триады башен с врагами. Т.е. в подчинении контроллера уровня. И тогда получится что контроллер башни получает от вьюхи башни "На_Меня_навели_мышкой", чешет затылок, ибо не знает что с этим делать, и диспатчит дальше. Контроллер уровня получает это событие, дергает контроллер хинтов "слышь чувак, а покажи как мне хинт для вот этой башенки" и все довольны.

//**********************

Короче моск пухнет уже, жду ответов:) Спасибо)

Добавлено через 30 минут
Перечитал еще раз.

У меня тут видимо слегка путаница с общением между родительским контроллером и детьми.

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

Да)) в довершение ко всему меня интересует наследование.
Простейший пример. Есть какой-то шаблонный клас юнита. От него наследуются все остальные юниты. Если делать "Как обычно" - то получится что-то вроде:
Вложение 25730

А если делать чтоб всё по правильно-мвцшному, то видимо что-то примерно такое?:
Вложение 25731
Ну не без того что к примеру каких-то две модели у нас окажутся идентичными, то получится "сэкономить" на классах (хотя тут уже впору будет задуматься, а стоило ли разбивать на разные классы вместо того чтобы сделать одну триаду "юнит", а в нем просто unit.type = (1 || 2 || 3) ).

Я прав насчет второй диаграммы?

З.Ы. Пунктир - "наследует"; Стрелка с ромбиком - "Содержит в себе".

То что ты хочешь сделать - это не простейший пример. Нужно будет много раз переделывать чтобы реализовать все эффективно. Но если есть время и желание - то ОК.
По поводу описания:
Первое что бросается в глаза это то, что у тебя модель имеет какую-то декоративную функцию.
Я придерживаюсь этой схемы:
http://upload.wikimedia.org/wikipedi...agram2.svg.png
Зачем контроллеру хранить модель у себя? Пусть он поместит ее в модель уровня.
Затем на диаграммах показано что вьюшки не имеют ссылки на модель. Да, можно заставить модель и представление общаться через контроллер, но здесь пусть лучше вьюшки знают что они отображают. Тогда если модель изменится - вьюшка сразу об этом узнает и обновится.
Далее: вьюшки могут создавать не только контроллеры. Можно сделать так, чтобы вьюшка уровня слушала свою модель на предмет добавления/удаления моделей башен и сама добавляла/удаляла себе соответствующую вьюшку. Контроллер уровня может поступать так же с контроллерами башен.
На второй диаграмме ты зачем-то дублируешь параметры moveable и size. Но ведь раз и контроллер, и представление имеют ссылки на модель, то они всегда могут получить эти параметры из нее.
По вопросам:
В твоем случае главная вьюха действительно не нужна. Пусть ее роль выполняет главный класс.
Всплывающее окошко ни вьюха башни, ни вьюха уровня отображать не должны. Ты забыл об интерфейсе. И вьюха уровня, и всяческие панельки должны иметь определенного родителя. Вот он и должен это делать.
Зачем делать триаду для хинтов? Например хинт отображает информацию о башне. У башни есть модель, в которой она полностью описана. Так пусть моделью хинта будет модель башни.
Контроллер интерфейса (контроллер хинтов или сразу вьюшка интерфейса) получает событие от какой-нибудь вьюшки "на меня навели", смотрит какая у этой вьюшки модель (если она вообще есть), создает соответствующий хинт, дает ему модель этой вьюшки и засовывает хинт в вьюшку интерфейса. Как-то так.