Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   [Паттерны] AS3 MVC (http://www.flasher.ru/forum/showthread.php?t=212486)

namespaces 24.02.2016 02:56

AS3 MVC
 
Привет.
Создаю на Эйр небольшое приложение для телефона. Думаю все таки понять суть и создать свой кастомный MVC. До этого имел дело с PureMVC, Robotlegs, SomaFramework и т.д. Давно привык использовать готовые фреймворки, чем изобретать свой велик.
В общем, прочитав несколько статеек про MVC, вроде все ясно

Код AS3:

var model:Model = new Model();
var controller:Controller = new Controller(model);
var view:View = new View(model, controller);
addChild(view);

Но везде пишут только про стартовый запуск паттерна, а как двигаться дальше? Скажем, если у меня 10 моделей, 20 контроллеров и дофига вьюшек, как все это связать в одно целое?

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

Буду очень благодарен за любые советы.

Wolsh 24.02.2016 09:11

Бэкграунд является Данными приложения? Как говорится, нафига козе модель.

Добавлено через 2 часа 15 минут
Такой подход, действительно, распространен — когда "любое изменение на экране должно инициироваться Моделью". Но это вовсе не значит, что он хорош и обязателен. Это избыточность архитектуры.
Модель должна заниматься данными: хранить их и обрабатывать, производить вычисления и осуществлять логику Приложения. Если изменение фоновой картинки никак не влияет на логику приложения и его данные, оно никак не связано с Моделью. Ваше затруднение возникает из-за того, что Вы абстрагируете фоновую картинку в отдельную самостоятельную триаду MVC, создавая таким образом отдельное самостоятельное приложение "Меняющийся фон". В рамках этого приложения всё законно, есть модель, хранящая данные о всех картинках, текущей картинке, и вычисляющая следующую картинку и момент изменения, и посылающая событие для Вью. Вопрос только в том, нужна ли эта триада "главному" MVC Приложения, или может прекрасно существовать в его Вью. Ведь всё, чем "Меняющийся фон" занимается, имеет отношение только к Вью и никак не меняет данные самого Приложения. Если завтра Вы захотите поставить на фон видеоролик, или скриптованую 3D-сценку, это никак не отразится на логике Приложения. Это вопрос только отображения, и им должна заниматься Вью. Для того Вью и отделяли от Модели, чтобы совершенно свободно менять варианты отображения, не внося никаких изменений в логику.
Ну а после того, как Вы согласитесь, что место этой штуке — во Вью, скорее всего отпадет и необходимость оформлять ее как MVC: контроллеру там нечего контролировать, нет никакой интерактивности; нет Данных и логики, которые был бы смысл защитить в Модели. Есть только Вью со СКРИПТОМ, или, как говорили раньше, сценарием. Простым самодостаточным сценарием, независящим ни от чего.
Даже если смена картинки подразумевается не по таймеру, а при переходе Приложения к другому "разделу" или "состоянию", то это изменение является глобальным для всего Вью и должно инициироваться из Вью. То есть Вью получает от Модели событие смены Состояния, а смена картинки является частью реакции Вью.

namespaces 24.02.2016 13:31

Цитата:

Сообщение от Wolsh (Сообщение 1192110)
Бэкграунд является Данными приложения? Как говорится, нафига козе модель.

Спасибо за развернутый ответ.
Насчет бекграунда скорее всего так и сделаю. Это просто был пример.

Представим, что приложение имеет подключение к базе данных, читает конфиг файл и для сохранения состоянии (сессии) записывает данные в Sharedobject. А также несколько окошек, игровую сцену, звуки и т.д.
Окошки в виде уведомлений могут всплывать в разное время, если отсутствует подключение или проблемы с базой данных, то вместо ошибки молча записывать-читать с локального файла.
Вопрос лишь в том, как Вид слушает ответ от 5 моделей? Какая роль у контроллера? Кто добавляет этих окошек на сцену?

Wolsh 24.02.2016 14:16

Цитата:

редставим, что приложение имеет подключение к базе данных, читает конфиг файл и для сохранения состоянии (сессии) записывает данные в Sharedobject.
Это Модель.
Цитата:

А также несколько окошек, игровую сцену, звуки и т.д.
Это Вью.
Цитата:

Вопрос лишь в том, как Вид слушает ответ от 5 моделей?
MVC это не паттерн, а парадигма. Паттернов в нем может быть еще десяток разных. Если Вам действительно необходимы 5 моделей (а это не факт), можно сделать им Фасад. Можно и не делать, а иметь 5 "независимых" MVC. Это уж надо решать в конкретной ситуации.
Цитата:

Какая роль у контроллера?
Разделить Вью и Модель так, чтобы не было жесткой связности. То есть, чтобы Вью не пришлось импортировать Модель (что явный нонсенс). Вообще, в отличие от вашего представления в первом посте, Вью и контроллер-то не импортирует и не имеет на него ссылки. Потому что Вью должна только посылать события о том, что юзер сделал то-то и то-то. У Вью нет логического языка, то есть Вью не может формулировать сообщения в виде "юзер убил танк №112". Вью не берет на себя логику. Вью может сообщать только "юзер нажал клавишу Пробел". И вот здесь, по парадигме MVC, включается контроллер, поскольку Модель живет в своем мире Данных и понятия не имеет ни о каких клавишах и мышках. Контроллер — тот, кто Знает, что именно в текущем режиме Приложения делает клавиша Пробел. Какой именно метод Модели надо вызвать. Потому что в режиме Меню клавиши "делают" одно, в режиме Чата другое, в Инвентаре — третье, а в бою — четвертое. Контроллер контролирует действия юзера в зависимости от режима (mode), в котором находится Приложение. Переключение этих режимов может менять сами контроллеры (почему, собственно, выгодна схема с событиями от Вью а не вызовами методов контроллера напрямую — замена контроллера в такой ситуации была бы крайне затруднительна). Таким образом контроллеры инкапсулируют в себе поведение. Не логику Игры, не вычисления, а именно трактовку действий юзера в условиях текущего Состояния приложения, характер интерактива. Потому что эту трактовку не может себе позволить ни Вью, максимально удаленная от логики и данных, ни Модель, максимально удаленная от способа отображения данных и взаимодействия с пользователем.

namespaces 24.02.2016 16:04

Теперь все стало понятно, разложили все по полочкам. Спасибо за помощь.


Часовой пояс GMT +4, время: 20:11.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.