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

[in4core]

Dukobpa3 ну хорош, ты то уж тоже)) Тему создавал чтобы получить ответы, иду ли я в корне не туда, или моя реализация имеет право жить.
А за то что люди ответили, так я благодарен, узнал для себя еще пару новых вещей, особенно от катяры и artcraft

[artcraft]

хм, странно, а рейтинг мой не шелохнулся

[in4core]

))) а теперь

[artcraft]

теперь всё в полном порядке

[Котяра]

всё -таки прокомментирую про порочный круг:

1. пользователь нажал включить
2. контроллер записал в модель - включено
3. модель рапортовала - произошли изменения
4. вью выставил положение компонента во включено
5. выключатель сообщил контроллеру что он теперь включен
6. см пункт 2

классический MVC
1. пользователь нажал включить - вью отрапортовало контроллеру
2. контроллер записал в модель - включено
3. модель рапортовала - произошли изменения
4. вью выставил положение компонента во включено

MVP
1. пользователь нажал включить - вью отрапортовало контроллеру
2. контроллер записал в модель - включено
3. модель рапортовала - произошли изменения
4. контроллер выставил для вью положение компонента во включено

MVVM (PM)
1. пользователь нажал включить
2. контроллер(pm/vm) записал в модель - включено
3. модель рапортовала - произошли изменения
4. контроллер(pm/vm) выставил для у себя свойство включено.
5. путём биндинга (а без него этот паттерн бессмысленен) вью поменяло свой стэйт

[in4core]

Котяра - у тебя получается что при любом раскладе модель рапортует кому либо об изменении. А зачем это делать, если быстрее запустить метод вью из контрола? А в модель писать лишь для того, что в какой то момент во вью понадобится узнать некую переменную.
Вот пожалуйста пример :
Запускаем приложение, инициализируется контроллер и получает данные с сервера, в данном случае он получает некий ID игры, мы несомненно знаем, что ID нам пригодится потом, поэтому запишем его в модель. При запуске же в некотором текстовом поле во вьюхе нам надо показать этот ID. У нас 2 варианта, рапортовать из модели после ее изменения либо просто изменить модель и запустить метод вью из контрола. Допустим мы не будем рапортовать , а запустим метод view.setID(idData) . Во время работы приложения нам потребуется показать или узнать этот ID из вью , для этого мы дернем геттер модели.
Ага все удобно. Можно было бы воспользоваться и рапортом модели, тоесть вариант 1, принципиальных различий в этой ситуации мы не видим.
Продолжаем так же работать с нашим приложением, и теперь нам понадобится какая то другая переменная, которая нам пригодится по ходу дела, но при ее получении вид перерисовывать не надо. Записали значит в модель. Во время работы приложения дернули геттер модели, узнали эту переменную.
__________________________________________________________________________________________
Тоесть я хочу понять, и никто из вас пока не может объяснить конкретно почему
Записать данные в модель , а из модели рапортовать к вью - ПРАВИЛЬНО , нежели записать в модель, но сразу же и запустить метод вью.
Я подозреваю, что мой подход вполне имеющий право на жизнь, и назвать его быдло кодом нельзя. Суть и архитектура от этого не меняется, кроме того, что теперь нам не приходится писать лишние dispatchEvent(UPDATE) в модели на каждый сеттер и это приятно. Кроме всего прочего, если модель у нас все таки будет держать всю логику, а контроллер будет тонкой прослойкой, как говорит нам вики, то опять же смысл не поменяется :
controller :
model.setVar = vars ( в этот момент проходят там разные проверки и прочее и setVar становится такой как нам надо, например распарсенной)
view.update(model.setVar);

И да, вью полюбому будет держать модель, а чеж нет?!
View:
if(model.setVar[5] ) ...

[maxkar]

Тоесть я хочу понять, и никто из вас пока не может объяснить конкретно почему
Записать данные в модель , а из модели рапортовать к вью - ПРАВИЛЬНО , нежели записать в модель, но сразу же и запустить метод вью.

Только потому, что к одной и той же модели может быть привязано несколько view или controller. И несколько контроллеров, кстати (я могу, например, отображать модель в виде картинок и в виде текста. Каждая будет иметь свой контроллер). В этом случае в контроллере вместе с моделью нужно везде таскать эти все view. И при добавлении нового view (для той же модели) придется по всем контроллерам искать, где же используется этот элемент данных и кто от него зависит. Применения - например, в статусной строке и "области подсказок окна" могут выводиться данные, зависящие от модели в "основной" части окна. При этом в статусной строке мы можем в дальнейшем добавлять еще различные индикаторы статуса (т.е. в момент разработки полных их набор мы не знаем и делаем их последовательно).

Суть и архитектура от этого не меняется, кроме того, что теперь нам не приходится писать лишние dispatchEvent(UPDATE) в модели на каждый сеттер и это приятно.

Ну так нужно по-другому модель собирать, чтобы не приходилось dispatchEvent писать .

model.setVar = vars ( в этот момент проходят там разные проверки и прочее и setVar становится такой как нам надо, например распарсенной)

Угу. А через месяц в model Добавится поле parseError и setVar будет менять еще и его в случае ошибок. Вы точно уверены, что хотите после этого искать все контроллеры, работающие с моделью, из контроллеров смотреть, поддерживает ли view это поле и обновлять view? Этот подход может привести к очень интересным ошибкам. Особенно через несколько подобных изменений.

[in4core]

maxkar , об данной конкретной ситуации разговор и не идет. Хотя даже если рассмотреть ее, я не понял откуда у вас появились такая странная логика. Вот пожалуйста

mainController.as
initialize() {
globalModel = new GlobalModel()
globalView = new GlobalView(globalModel)
controller1 = new Controller1()
controller2 = new Controller2()
view1 = new View1(globalModel) // создается в controller1 
view2 = new View2(globalModel) //  создается в controller2
.....
function onMainControllerGetData()
{
   globalModel.vars = someVars;
   globalView.update(globalModel.vars)
}
....
Controller1.as
function onController1GetData()
{
   globalModel.vars = someVars; // этой строчки может и не быть вообще
   view1.update(globalModel.vars)
}

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

[Wolsh]

Даёшь каждой вьюхе свой контроллер? Нафига контроллер статусбару, который честно показывает данные и ничего больше? Нафига приложению сто контроллеров, это типа процессора i100? Быстрее думать будет? Или чтоб хакеры обломались?))
У Вас какое-то странное понимание слова "парадигма" и назначения шаблонов. Вы берете от шаблона название, и только. Заложенные в нем принципы, типа оповещения событиями от Модели, имеют под собой четкое обоснование – количество Вьюх изначально вообще неизвестно. Совершенно не важно, сколько их, и это базовая концепция MVC. То есть MVC имеет смысл применять, когда ситуация именно такая. Какие-то другие варианты "как удобно мне" это не шаблон, а "что вижу то пою". Нет смысла притягивать за уши изуродованный труп MVC. Дайте этому свое название, опишите все преимущества такого решения и станьте автором нового шаблона. Докажите, что MCVCVCVCVCVCVCVCVCV это круто.

[alexcon314]

in4core, дело в том, что все это действительно не так уж и важно, следовать "букве закона", или писать находу собственные импровизации, очень может статься, что и неплохие, да, а может и наоборот.
Вы поймите суть: абстрагироваться по максимуму от всевозможных частностей. Например, view.setID(idData) - это частность, т.е. фактор имеющий конкретное значение в конкретном месте отдельно взятого проекта, например, вам сейчас и здесь так делать "удобно". В другом проекте или даже по мере развития того же этот фактор вообще может и не встретиться или может иметь совсем другое значение и т.п. А ваш класс вью уже завязан на эту частность и бог знает сколько таких заплаточек у вас будет еще. А dispatchEvent(UPDATE) - это как раз способ от этой частности уйти раз и навсегда.