![]() |
MVC. Контроллеры
Здравствуйте.
Решил попробывать написать проект и использованием MVC-модели. Если я все правильно понял, Модель - это хранилище данных, ссылки которые раздаются вьюверам. Вьюверы в свою очередь обновляют данные когда изменились данные в модели. Контроллер - это механизм который создает вьюверы, модели, а так же осуществляет создание связей между ними. Знаю что глобальный класс должен передавать в главный контроллер ссылку на себя и все но у меня пока немного не так. Пока создаю модель без вьюверов, хочу пройти сначало по моделям с контроллерами. основной класс Код AS3:
Код AS3:
Код AS3:
P.s. Силой святого компилятора призываю к обсуждению Babylon =) |
Цитата:
Контроллер имеет ссылку на Модель. Модель имеет только на Вьювер. Вьювер имеет на Модель и на Контроллер. |
Цитата:
|
Цитата:
2ТС, прочтите это. |
Цитата:
|
Модель это не просто хранилище данных, модель - это состояние программы, которое вполне может изменяться и самостоятельно (действие гравитации в игре, нанесение урона юнитам стоящим в огненной луже, изменение индексов на онлайн бирже)
Модель описывает всю логику программы, высылает уведомления при возникновении некоторых событий. Модель имеет интерфейс для чтения/внесения изменений в свой мирок. Модель ничего не знает ни про визуализатор, ни про контроллер. Визуализатор - подключаемый модуль для отображения модели. Он имеет ссылку на модель. Визуализаторов может быть несколько, они могут быть разными (2д, 3д) и все они сразу могут отображать одну модель. Визуализатор читает модель, слушает её события изменения, обновляет себя сам в соответствий с текущей ситуацией в отображаемой им модели. Визуализатор слушает действия пользователя и высылает их события. Вьювер так-же имеет некоторый интерфейс, он может быть заморожен контроллером при выполнении какой-то операций. Контроллер имеет ссылки на оба компонента. Он приостанавливает ход выполнения в модели, добавляет новых игроков на бирже, активирует дополнительные режимы. Контроллер слушает визуализатор на предмет действия пользователя, анализирует и принимает решения по изменению модели. Имхо, на истину не претендую, так делаю сам. |
Спасибо Tails, доходчиво написано.
То-есть по сути, модель это и есть модель со всеми вытекающими ему свойствами, может сама видоизменяться но не участвует на прямую с внешними процессами, за это отвечает контроллер. Но остается открытым мой вопрос, контроллер получил событие создать новый контроллер, каким образом он это делает? |
Есть глобальная модель, для описания всех необходимых данных в своём мире, она может создавать дополнительные под-модели. Аналогично и для вьюшки с контроллером.
Вы в главном коде единожды создаёте глобальные: модель, вьювер и контроллер, а те уже сами по ходу выполнения решают, что им нужно. Главный контроллер может создать дополнительные под-контроллеры для сохранения/загрузки файла, вьювер может создавать дополнительные под-вьюверы для отображения бэграунда/юнитов и т.д. пс. Выше стоящий контроллер должен принимать решение о смене своих детей - под-контроллеров. |
Я для себя использовал иерархический MVC, То есть у меня не было обособленных трио, у меня были контроллеры с некоторым уровнем вложенности, в главном контроллере были созданы вьюшки во вьюшках; были созданы в нем же модели в моделях. То есть каждой вьюшке передаем либо какую-то модель в главной модели, либо всю модель целиком.
Добавлено через 44 секунды Словом, выбирайте то, что вам будет удобнее. Эта штука у каждого разработчика своя. |
Понял. Буду пробывать)
То-есть примерно так Код AS3:
Цитата:
|
AlexCooper,
Главная цель - максимальное уменьшение зависимостей в пользу лёгкой последующей модернизаций/обнавлений кода. Каждый класс должен выполнять строго отведённую ему область задач. Чем меньше он знает о том, что твориться вокруг него - тем лучше. Отлично, если он вообще не ведает что над ним и следовательно легко может быть заменен. |
В таком случае как бы Вы видоизменили мой код?
|
Модель, получив данные, парсит их. Видит, что есть новый не авторизованный пользователь - высылает событие NEW_USER. Отдельный под-контроллер, заранее подписанный на конкретно это событие, получает уведомление и производит необходимые действия.
До тех пор, пока контроллер не завершит обработку, новый юзер в модели числится как не авторизованный. |
Благодарю
|
На самом деле удобно иметь несколько контроллеров для вида, модели и глобальный для ядра.
В глобальном лучше размещать основные команды ядра. Контроллер вида обслуживает виджеты, а контроллер модели сервисы. Скелет вида, модели и контроллер команд, у меня естественно XML, ноды которого передаются в соответствующие конструкторы дисплей контейнеров вида , которые затем рендерятся виджетами. Соответственно вся иерархия в виде графа, который агрегатирован по parent id соответствующей xml ноды. Нода вида ... Нода Коллекция виджетов ..... Нода Коллекция команд и хэндлеров .... Нода Коллекция сервисов |
Цитата:
Пока написал вот это Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
Код AS3:
|
Это всё красивые слова
В основе DI все равно фабричный подход. Сначала надо правильно создать ядро, а уже потом сделать нужные классы "слабосвязанными" за счет интерфейсов. Собственно для этого их и придумали. Добавлено через 17 минут Цитата:
Добавлено через 41 минуту Цитата:
|
Вложений: 2
Главный контроллер создает главный вьювер и главную модель приложения. И прослушивает модели на изменения.
В зависимости от изменения главной модели он создает "worker"-ы под-контроллеры в которые передает ссылку на модель которую они обрабатывают и ссылку на главную модель для изменения всего приложения. Воркеры меняют эти модели которые в свою очередь генерируют соответсвующие события. Ну и подписанные контроллеры или вьюверы начинают свою работу после изменения моделей. |
Юзер у вас как то мимо данных проскакивает. От кого он получает измененные данные
|
Да, забыл уточнить, юзера заполняют воркеры, когда пользователь не зарегистрирован, в моделе пользователя срабатывает событие "регистрация" и тут уже в обход главной модели вызывается контроллер REG главным контроллером который слушает модель пользователь.
|
Жутко извиняюсь за выбор темы! Начал вникать в robotlegs и конечно начал с примера Hello World, но к сожалению столкнулся с проблемой после нескольких минут. У меня нет класса Actor, swc подключены обе и Context видет точно, много ещё всяких классов. Может кто то сталкивался с этим, в чем может быть дело?
Добавлено через 21 минуту Вот что получается. В последней 2.1.0 версии нет вообще актера, он есть в старой версии. Уроки ( которые лично мне нужны, я не смогу понять что там к чему не посмотрев ) я пока только для старой версии нашел. И получается, что они больше чем бессмысленные. Если кто то знает о примерах для второй версии, поделитесь. |
okouser Спасибо! Вообще жалко, что нет или возможно просто тяжело найти, принцип работы на русском или хотя бы примеры на других языках. Везде написано - документации и так хватает и что robotlegs служит каким то звеном для связи с внешним миром. Но каким именно звеном или какое место в модели MVC он занимает, мне не понятно.
|
Цитата:
я смог найти только описание про обьявление инжектируемых классов на хабре, три видео на ютубе ( сирия одних уроков посвящена первой версии и для флекса, вторая просто для первой версии и третья вроде второй ) Посмотреть про первую версию можно, но понятно становится, только то, что есть какие то законы при использовании фраймворка ( наследоваться нужно от чего то конкретного, обьявление классов в специальных как я понял функциях и тд ). Так же если нет ранее существовавшего класса Actor , то скорее всего что то есть в замен, а если это не так, то у меня ещё больше вопросов появляется, на которые, примеры по вашей ссылке не могут пока мне ответить. я ожидаю в них увидеть строгое разграничение на модель, вьюшку и тому подобное, но там нет этого, там все классы не понятно как то в кучу сложены. Но раз говорят все, что его нужно знать, то буду искать дальше. Если у кого то есть ссылки - делитесь) Добавлено через 1 час 25 минут По истечению двух с половиной часов пришёл к выводу, что старые статьи помочь вообще не могут. В статьях первой версии есть injector.mapClass и тому подобное, во второй части нет такого вообще! Схожесть только в метатэге [Inject], остальное кардинально отличается. Как быть не даже не знаю. |
Цитата:
....Сейчас посмотрел ваши ссылки, которые Вы привели выше, сейчас буду их смотреть. И самое главное - Спасибо Вам ! |
Цитата:
|
Цитата:
|
Цитата:
Добавлено через 44 секунды У меня сейчас чувство какой то неполноценности) Добавлено через 1 минуту И визуально и в папке поиском искал и нет там документации. Добавлено через 6 минут Архив у меня называется robotlegs-framework-master.zip и нет там не html не docs... |
okouser Спасибо Большое! Ушел читать)
Добавлено через 1 минуту okouser Уще раз Спасибо! я даже и не мечтал о такой справке! Добавлено через 4 часа 20 минут Сижу разбираюсь и у меня появился вопрос о котором я думаю с самого начала знакомства с MVC. И на этот раз я решил его задать. Создавая онлайн игру, первое что приходит на ум - разбить её логически. Пакет - юзер, пакет - игра и.. для примера этого будет достаточно. И так же надо представить, что когда в игру заходит пользователь, то у играющих появляется окно с фото и именем вошедшего. И вот тут начинается небольшая путаница, как должно быть - оба пакета должны иметь вью ( у пакета юзер вью собирает ту самую вылезающую табличку ) или только в пакете игра? И ещё вопрос - если в каждом пакете будет полноценное MVC, то как их более правильно обьединить? Или уже все пакеты ( для примера представить, что пакет это файл ) строить как одну глобальную MVC ? я могу представить, что решений очень может быть много, но я боюсь отклонится с правильного пути - посоветуйте что можете. Добавлено через 4 часа 38 минут и чтобы не создавать второй раз тему то спрошу http://www.flasher.ru/forum/showthread.php?t=202436 |
| Часовой пояс GMT +4, время: 20:51. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.