Лучше иметь 3 контроллера - для виджетов вида, вида и модели, модели и сервисов. Ну эт на любителя.

Три контроллера на все приложение? Это очень на любителя.

Расскажите, сколько должно быть у профи?

Этот вопрос как и многие другие подобные нашли свои ответы в этом обсуждении.

Что бы их найти надо прочитать много страничек. Раз Вы Zebestov Вы и расскажите о лучшей практике.

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

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

простой пример: главной контроллер игры..создает контроллеры юнитов, передавая им их маленькие модели и вьюшки...дальше у кого как. много зависит от структуры

Кто на, что подписался:)

Отсылка к указанной теме неслучайна. Основное, что я вынес из этой дискуссии, — это отсутствие жестких правил реализации MVC. Поэтому и вопрос "как там у профи" счел неуместным. Эти самые профи до сих пор не могут решить кто тоньше: модель или контроллер.
Но вот определение "три контроллера на приложение" я расцениваю как стремление "централизовать" управление. Сколько контроллеров у меня? Столько, сколько потребуется для того, чтобы это самое управление "распределить".

Вы правильно расценили. Именно ядро должно быть толще, а MVC тоньше. Ну эт я как любитель рассуждаю.

В моих приложениях MVC лютует по всему коду от и до.

а как часто нужно пользоваться баблингом в MVC , стараться избегать его использования, и использовать только при большом количестве детей во вьюшке?

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

Баблинг заметно всё тормозит, поэтому лучше без него. Но иногда без баблинга не обойтись.

MVC – "разделяй и влавствуй", ядро – какой-то кусок приложения, на котором всё строится.
По мне это как сравнивать танцы и небоскрёб. Что Вы хотите сказать?

Я не сравниваю. Можете если хотите все интерфейсить, утолщяя приложение проксями и медиаторами , мне же ближе наследование от общего Сore. Тем более если Вы автор-одиночка. Смысл интерфейсов в заглушках. Вы работаете с тем что пока нереализованно, но есть некий концепт.

Та да:
А вот это вообще набор слов:
Или это и есть "Ваша реализация MVC"? Тогда, пожалуйста, подробней.

Интересно, сколько у вас событий, что бабблинг тормозит?

Мне тоже интересно. Как я заметил, читая разные темы форума, Babylon является ярым приверженцем XML, наверняка он и в реализации структуры ТРУЪ MVC есть.

И все-таки Вадим вам дал прекрасную ссылку на очень хорошую и плодотворную беседу, из которой следует, что MVC -это не 2 варианта развития событий: "общий Core" или "с проксями и медиаторами"

Это плохо? Ну тогда с вашей точки зрения все ООП со своими абстракциями, инкапсуляциями и полиморфизмами в опасности.

Тот же концепт даст пустой метод в классе, без реализации классом интерфейса.

Так-с, про XML уже сказали. Жду когда расскажут про агрегатирование.

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

Добавлено через 10 минут
dimarik, пожалуйста конкретизируйте свой вопрос.

Добавлено через 25 минут
Я то как раз за минимизацию использования интерфейсов. Но когда компоненты MVC разрабатывают разные люди наверно он необходим. Я даже в этом уверен. И повторяю - это не сравнение это следствие расширения функциональности. Посмотрите на Drupal. Его ядро только увеличивается и это плюс, а не минус. Вторым плюсом является использование механизма entity reference и типов сушностей - бандлов. На которых и строится агрегатирование. Понятно, что идейно всё это идет от Java, но в AS3 и близко этого нет.

Добавлено через 36 минут
Вы знаете не считал. Это было изначально не мое приложение.

Вот и дорассуждались. Демагогия.

okouser, инжекции заменяют один класс другим так чтобы Вы этого не заметили. При чем тут чистота кода? Что Вы собирайтесь менять в ядре??? И если уж соберетесь, то это затронет и интерфейсы и все классы которые его имеют. Извините за демагогию. Я не воспитан в ТЗ и слава Богу.

Добавлено через 5 минут
Я полностью разделяю точку зрения автора http://javascript.ru/optimize/antimvc
Роль DOM может играть XML

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

Бизнес-логика... Я про нее и не думал, а Вам почему то икнулось. Где я заменяю MVC на XML? Но в конструкторы видов и сервисов я действительно передаю xml ноды. Виды легко могли бы менять модель без С если бы не сервер... Так что контролер нужен а значит и MVC.
Можете меня считать демагогом, плотником или каменщиком.

Настаиваю на прекращении рассуждений на предмет целесообразности MVC как такового и высказываться все же в рамках названия темы: "Ваша реализация MVC"

"Ваша реализация MVC" - это типа с нуля создать свое с пересозданием существующих известных фреймворков? Кто по вашему будет на это тратить время, если помимо проекта и архитектуры еще предстоит возня с интерфейсом, дизайном, логикой, тестированием, отладкой приложения?!
Можно было бы скопирнуть сюда свои кастомные классы, если вы имели ввиду только как "Ваше понимание MVC", нежели "Ваша реализация". Т.к. написание фреймворка это не только завернуть все в пакетик SWC и продолжать творить по этому шаблону.
Каждый проект это новый MVC.

ps Ничего дельного не сказал, но ухх как высказался)) полегчало.

почитав темы про mvc я понял что структура вьювов должна почти зеркально повторять структуру моделей,
но если нажали что-нибудь во вью, а она находится глубоко, а контроллера нет поблизости, передаем событие ближайшему контроллеру, но как этот контроллер может дать своей модели какую именно модель внутри нее нужно изменить(то есть как найти можель которая принадлежит именно этой вью ), вижу два варианта:
1. использовать метки (типо айдишников в БД).
2.все же создавать триаду "на глубине", и тогда контроллер будет знать к какой модели относится вью.

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


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

мне видится такое удаление:

1. вью диспатчит "removeMe",
2. его контроллер ловит событие, и вызывает у модели destruct.
3. модель диспатчит верхней модели "removeModel", так как у верхней модели есть ссылка на нее и ссылку надо удалить.
4. также это "removeModel" ловит вью удаляет слушатели и диспатчит событие для верхней вью, чтобы она ее удалила.
5.контроллер удаляет слушатели и диспатчит событие верхнему контроллеру , чтобы он его удалил(есть ссылка).

просьба строго не судить) я пытаюсь понять суть)

У каждой модели (ноды) как и вида должен быть id по которому контроллер узнает ее инстанс
Вид рендерится виджетами по модели, а контроллер обрабатывает их взаимодействие посредством событий.

получается что каждый вью хранит айди модели?
то есть получается порядок действий такой?
1. кликнули на вью,
2. диспатчим кастом событие, в котором передаем айди вью,
3.контроллер находит этот вью по айди
4. вытаскивает из него данные и айди модели
5.говорит модели записать данные во внутреннюю модель по айдишнику

так?

Ни один MVC фреймворк не стоит того, чтобы его пересоздавали.

Ты удивишься :)

Почему View дает модели указание на удаление? Это задача логическая, а не творческая — модель должна решать. Модель приложения так или иначе пришла к тому, чтобы вызвать метод destruct() у нашей модельки. В этом методе следует послать событие DESTRUCT, которое поймает отображение, подписанное на события своей модели. Отображение произведет необходимые процедуры очистки на внутреннем уровне и пошлет родительскому отображению событие REMOVE, чтобы оно, в свою очередь, удалило объект со сцены вообще.

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

dimarik, да делайте, что хотите.

Babylon, а по делу что-то ответишь?

2. Передается только ссылка на объект модели или вида, а вместе с объектом и его id. Вы правы Вид и Модель практически не отличаются. Вид работает с отображаемыми объектами, а модель нет. Вид ничего не знает о методах модели, а модель о методах вида. Но контроллер знает всё.

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

Ссылка идёт сразу на модель.

все виды "равноудалены" от контроллера и доступны по ссылке, но друг с другом могут образовывать некоторую иерархию, в зависимости от задач вашего приложения. В AS3 нет встроенных id для объектов как в объектив с

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

Zebestov, пожалуйста расскажите про иерархию контроллеров.