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

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)

- ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)

Котяра респект, думаю многим полезно будет почитать.
Теперь понятно , что такое MVP , однако пока непонятно, что если модель может менять вид и контроллер может менять вид, тогда как назвать такой шаблон ? Пропорции изменения не важны, просто ради факта интересно.
Ну и про 2 модели в виде, передача через конструктор, нормально? ты так делаешь бывает?

Цитата:

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

паттерн - быдлокод.

Цитата:

если модель может менять вид

не может. модель может только сообщать о своём изменении. как таковых ссылок на виды и контроллеры она не имеет (только опосредованно через подписку на события)

Цитата:

про 2 модели в виде, передача через конструктор, нормально?

нет просто ссылкой.
например у вида есть 2 модели
camera и coordinates
просто по ссылке устанавливать при создании вида.

Код AS3:

var view = new View();

view.camera = camera;

view.coordinates = getViewCoordinatesById(id);

Я вообще последнее время стараюсь делать конструкторы без параметров.

а еще бывают
PAC Presentation-Abstraction-Control
MVVM Model-View-ViewModel
MVCS Model-View-Control-Service
VCLSD View-Control-Logic-Service-Data

http://www.flasher.ru/forum/showthread.php?t=173879
Где ж вы все были когда я этот вопрос поднимал?

Цитата:

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

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

Тоесть архитектра такая :
Controller can :
- view.update(vars)
- view.addEventListener
- model.var = someVar
Реализация MVP - как выходит.
А вот как назвать такой паттерн :
Все тоже как в примере выше, но есть еще и
view can :
model.addEventListener
model can :
dispatchEvent

Тоесть все в скупе

если взять MVP и добавить в него право View читать модель
то это разрушит всю красоту идеи

MVP это элегантная трёхэтажная конструкция а не "порочный" замкнутый круг как в классическом MVC

выгода МVP в простоте отладки и тестирования
и ценой за это является именно отсутствие прямого доступа вьюхи к модели

что получится если взять птицу и приделать ей две пары копыт от коровы?
монстр! :)

Добавлено через 25 минут

Цитата:

Сообщение от in4core (Сообщение 1074693)

Нету класического и не класического МВС

MVP и есть не классический МVC
Мне кажется его назвали MVP а не MPV или VPM именно в честь MVC

Добавлено через 47 минут
Напишу подробнее о "Порочном круге"

представьте себе программу из одного тумблера, вот такого:
http://dribbble.com/system/users/984...jpg?1328832199

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

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

Цитата:

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

Так кто же говорит о том, что нужно создавать такие круги? Разговор шел о конкретных мини реализациях методов.

Смотри, есть у нас допустим имя игрока в игре, это имя неизменно, значение имени получаем с сервера. Получили, записали в модель, модель оповестила вью - имя начертилось, либо другой вариант, записали в модель, на всякий случай для хранения, но обновили вид прям из контроллера.
Другая ситуация , баланс игрока. Может допустим меняться постоянно, но и значение его тоже нам нужно держать в памяти. Опять же по приходу данных мы можем писать в модель и обновлять вид из контрола, а может диспатчить из модели. Тоесть по сути разницы принципиальной никакой. Но в какой то определенный момент, в виде нам требуется узнать эту переменную, значит ссылку на модель иметь надо.
Единсвтенное что из всего этого понятно :
Мвс может быть реализован 2 разными методами - обновление вида через модель, и обновление вида через контролл. Причем разницы принципиальной между ними нет, но если использовать сразу 2 принципа, в голове и коде будет каша, поэтому лучше ограничится одним.
Мвп - сначала котяра сообщил, что о том что я говорю это МВП, затем прочитав статью стало понятно, что в МВП - вид не имеет ссылку на модель, но в этом случае жутко неудобно запускать механизм - * контрол дай мне занчение модели * , поэтому собственно не понятно, почему паттерн живет.
___________________________________________________________________________________
Так что вывод таков использовать кастомный МВС, что собственно я и делал, до создания темы

Controller - getData, setModelData , view.update(modelData or parsed_ModelData);
Model - setData
View - call to Controller

Либо

Controller - getData, setModelData
Model - setData , call to View
View - call to Controller , getEventFromModel , updateMethods by changing model

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

Цитата:

Так что вывод таков использовать кастомный МВС, что собственно я и делал, до создания темы

Ты нахрена тему поднимал?
Я дважды задавал один и тот же вопрос. (это третий)
Ты его дважды проигнорил.

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

Пацан к успеху шел.