Хорошее MVC

[fish_r]

Вот такой вопрос в разрезе MVC. Предположим использую я в программе какой-то внешний, по отношению к программе объект. Он также имеет структуру MVC. В моей программе он отображает содержимое, которое моя программа ему сообщила ранее и изменяет его, специф. образом, по сигналу моей программы. Так как же их завязывать? Какая часть этого, внешнего, объекта будет выражать его самого, что мне экземпляры контролов создавать что ли? Тогда не странно ли будет создавать контролл а добавлять на сцену переданную им ссылку, а общаться опять же через контролл? Что будет интерфейсом этого объекта? Ведь мы привыкли создавая объект, нами он написан или нет неважно, общаться с ним же, а не с его контролом. Не создается впечатления черезголовуштанынадевания?

[etc]

Если это внешний объект, то у него должен быть интерфейс модуля и работать мы с ним должны как с view если он таковым является.

[fish_r]

А как это "интерфейс модуля"?
Подумал, подумал... В этом случае "фасад" подходит, который является DisplayObjectContainer-ом. Приложение общается с ним думая, что он и есть объект, а он сообщает контролу всё необходимое, в тоже время использует преимущества InteractiveObject-а (подписка на события и пр.). То есть мы можем его и "пощупать" и сказать ему что нибудь, вместо того, чтобы "щупать" одного, а говорить другому.
Как такой вариант?

[fish_r]

Ещё один момент есть... Сам с собой разговариваю ... . Смущает то, что контролл зачастую просто транслирует данные через свои сеттеры в сеттеры модели получается дубляж переменных в обоих классах.
Насколько плохим тоном является размещение в сеттере контролла сеттера модели? Без промежуточных переменных, когда они никак не используются в контролле, конечно. То есть получается конструкция типа:

 
public class Controll() extends EventDispatcher
{
...
 
     private var _model:Model = new Model();
 
     ...
     public function get param():Object { return _model.param; }
     public function set param(obj:Object):void
     {
          if  ( _model.param === obj ) return;
           _model.param = obj;
 
     }
...

[Dukobpa3]

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

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

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

[fish_r]

роботлегс не читал, а в pureMVC нотификешен - это объект-событие с именем и данными, так кажется?

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

а там в методе-слушателе сразу дергается сеттер модели? если конечно цель - только передать в модель новые данные.

[Dukobpa3]

ну суть в том что нотификейшен имеет имя и данные и это впринципе всё что надо знать.

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

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

Но опять же по ситуации))) Панацеи нету

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

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

[fish_r]

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

...
- коннектор посылает нотификацию "я получил вот такие данные"
- хостКонтроллер получает эту нотификацию, видит данные, парсит
...

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

А... или это, чтобы удерживать уровень абстракции?

[Котяра]

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

[Dukobpa3]

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

А... или это, чтобы удерживать уровень абстракции?

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

Та и как Котяра говорит проще ведь сделать список нотификация - хентлер, чем помнить адреса каждого внука и дергать напрямую детей сеттерами.

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

И не путайте нотификации с событиями. Нотификация это глобальная муть, там своя схема, вникал как-то, но на пальцах долго объяснять. Есть глобальный контейнер в котором регистрируются все контроллеры, и эти контроллеры говорят глобальному контейнеру какие нотификации им удобнее слушать. А контейнер потом получает все нотификации и растусовывает по тем кто на них подписывался.

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