|
|
|||||
блогер
Регистрация: Jun 2005
Адрес: Господи пожалуйста не Новосибирск
Сообщений: 6,598
Записей в блоге: 17
|
Новый вопрос созрел: хочу сделать V+MC, что я делаю:
Создаю класс, ни от кого ни исследующийся, в котором будет происходить вся логика, который будет изменять свои же свойства. Ему в конструктор передаю hostisplayObjectContainer и в него добавляю вьюшку, которую эти же классом создаю. Когда нужно что-то обновить, вызываю у вьюшки метод render() или нечто вроде такого метода с нужными мне параметрами. Для MC + V делаю правильно?
__________________
Тут мужик танцует и поёт про флэш |
|
|||||
Et cetera
Регистрация: Sep 2002
Сообщений: 30,784
|
Psycho Tiger,
1) Типа того; 2) Модель снаружи приходит, у вьювера есть геттер-сеттер модели. То, что создает вьювер у себя внутри другие вьюшки отображающих элементы модели, контроллер не интересует. Максимум он подпишется у вьювера-контейнера на всплывающие события, либо сам контейнер ловит от вложенных вьюшек события и далее шлет результат (типичный пример — событие CHANGE у листа, которое формируется на основании событий SELECT у детей); По классам: контроллер не занимается обновлением состояния вьювера. Он изменяет модель, модель шлет событие. Ссылка на модель передаётся контроллером вьюверу на стадии сборки триады. В случае критичности частоты вызова обновлений, можно написать и геттеры-сеттры «x», «y», так и метод setPosition. Симбиоз так сказать. |
|
|||||
Регистрация: Dec 2006
Сообщений: 230
|
2ЦПУ; 2ДИМАРИК ::
"точно" ни разу не точно. Это только одна из реализаций, причем не самая чистая. Мука почитать (и на ВИКИ посмотреть) так выходит, что все данные+логика тройки - в модель. Это будет классическая имплементация MVC. И ходят оне парами как M+VC, т.е. при замене Вью меняем и Контроллер к нему. На эти темы уже копий переломано!... |
|
|||||
буду краток
модератор форума
Регистрация: Sep 2003
Адрес: Ближайшее Замкадье
Сообщений: 3,110
Записей в блоге: 28
|
Во всех реализациях MVC меня всегда смущали глобальности контроллера и модели. Если рассматривать модульную архитектуру приложения, то как мне кажется можно ввести понятие составной вью - который сам по себе может быть организован в виде mvc. Контроллер в таком вью является мостом между внутренними видами и внешним контроллером. Модель может быть как внутренняя так и ссылка на часть структуры внешней.
структура получается следующая: M1 - C1 - V1(m2-v2-c2) а не M1(M2)- C1(C2)-V1(V2) пример1: Если рассматривать с точки зрения клиент - сервер, то клиент это тоже вид, который диспатчит интерактивные события и слушает изменения данных, либо прямые команды от сервера ( который в данном случае выполняет ф-ции контроллера и модели данных верхнего уровня) пример 2: готовая форма лобби вступления в игры. в качестве данных принимает список открытых игр - диспатчит событие присоединения к игре. как это внутри отображается не важно - там может быть куча отдельных окошек, списков комбобоксов итп, организованных по своим mvc правилам. Здесь контроллер выступате в роли слушателя внешней модели и меняет внутреннюю, также он слушает внутренние вьюшки - меняет внутреннюю модель и диспатчит внешние видовые события ( типа вступить в игру/ создать игру). Для включения этого модуля(вида) в другую внешнюю MVC достаточно изменить "мостовую" часть контроллера. внтренняя структура остаётся неизменной. А вообще я последнее время сильно охладел к MVC - как к универсальному решению) выхожу из стадии abstraction freek) Хотя архитектуры проектов строю близко к МВЦ, но с учётом большей автономности модулей. PS: А готовые фрэймворки - *****) более менее только mate использую, и то в силу его "необязательности".
__________________
Отряд Котовскага Последний раз редактировалось Котяра; 06.04.2010 в 10:03. |
|
|||||
Регистрация: Dec 2006
Сообщений: 230
|
Главное, шоб оно оправдывало себя. Шоб не было такого, когда в порядке обновления Модели, надо пропускать событие с Вашего под-под-Вида через тучу Контроллеров БЕЗ ИЗМЕНЕНИЙ. Шоб не было MVC ради самого MVC. Возможно у Вас Контроллер выполняет роль Bridge (в M1 - C1 - V1(m2-v2-c2) а не M1(M2)- C1(C2)-V1(V2) и в пример 2).
Также иногда Контроллер просто на фиг выбрасывают из тройки как лишний ("необязательность"!). Т.к. весь инпут сразу в модель летит и обновляет ее эффективно. Т.е., имеем главное: отделяем представление от данных. Последний раз редактировалось Ariel; 06.04.2010 в 10:30. |
|
|||||
Скажите пожалуйста, что делает эта строчка кода:
Я так понимаю что она диспатчит событие на которое был подписан Вьювер в Классе-Контроллере? Выходит что super вызывает методы, переменные не только у родителей но и может передать событие в Класс где был создан экземпляр? Обьясните пожалуйста... Первый раз вижу такое... |
|
|||||
Регистрация: Dec 2009
Сообщений: 48
|
По логике вещей MVC, представление никак не связано с моделью. За передачу параметров представлению отвечает только контроллер. А задача контролера как раз и заключается из выдергивания необходимой бизнес-логики из модели и передачи готовенького представлению.
|
|
|||||
Регистрация: Mar 2010
Сообщений: 223
|
Ламерский вопрос.
При каких простых условиях говорят: "Вот это MVC!" ? ----------------------------------------------------------------------------------- 1. Т.е. что на что не должно иметь ссылок не при каких обстоятельствах? ----------------------------------------------------------------------------------- 2. Из Википедии: Цитата:
----------------------------------------------------------------------------------- |
|
|||||
Цитата:
|
|
|||||
Et cetera
Регистрация: Sep 2002
Сообщений: 30,784
|
Через контроллер. Точнее, как он решит, так и будет.
|
Часовой пояс GMT +4, время: 11:02. |
|
« Предыдущая тема | Следующая тема » |
|
|