Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 03.03.2018, 02:29
dimarik вне форума Посмотреть профиль Отправить личное сообщение для dimarik Найти все сообщения от dimarik
  № 71  
Ответить с цитированием
dimarik
.
 
Аватар для dimarik

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Каждому своё.
__________________
Воспитан в TimeZero. Работаю в Mail.ru.


Последний раз редактировалось dimarik; 03.03.2018 в 02:48.
Старый 03.03.2018, 11:20
Tails вне форума Посмотреть профиль Отправить личное сообщение для Tails Найти все сообщения от Tails
  № 72  
Ответить с цитированием
Tails
 
Аватар для Tails

блогер
Регистрация: Dec 2008
Адрес: г. Чебоксары
Сообщений: 2,259
Записей в блоге: 6
Да, в этом есть резон, выносить парсер отдельно от модели. Я делал разбор в самой модели, это не очень удобно.
__________________
Дети не должны знать о своих родителях

Старый 03.03.2018, 14:00
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 73  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Увидел тут мельком, речь зашла о ветвлении Моделей и Контроллеров. Я как раз до этого в своём проекте дошёл. Вот смотрите, есть игра, в ней у героя инвентарь. Его функционирование обеспечивается своей персональной триадой MVC, верно. Когда пользователь жмёт кнопку инвентаря, это событие слушает главная Вью и посылает событие в главный Контроллер. Главный Контроллер создаёт дочерний Контроллер инвентаря, который в свою очередь создаёт Модель и Вью инвентаря. Дальше все манипуляции обрабатываются дочерней MVC, и только событие на закрытие остаётся за главным Контроллером, который, получив его, свернёт всю лавочку и даст команду главной Модели продолжать.
Верно я всё написал?
__________________
Не сломано - не чини!

Старый 03.03.2018, 14:09
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 74  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Контроллеры создает контроллер. Модели — модель. Вьюхи плодятся во вьюхе.
Ко всем этим дочерним элементам есть доступ по геттеру, например.
Триада создается путем создания нового контроллера, который всегда имеет в аргументах как минимум две ссылки: необходимые ему для работы модель и вью.
Есть только один контроллер, который создаем модель и вью — это MainController. В нем создаются MainModel и MainView. Больше ни в одном контроллере модели и вьюхи не создаются. Они подаются в конструктор (или метод-инициализатор).
__________________
Поймай яблоко 2!

Старый 03.03.2018, 16:08
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 75  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
Цитата:
Сообщение от Zebestov Посмотреть сообщение
Контроллеры создает контроллер. Модели — модель. Вьюхи плодятся во вьюхе.
Ко всем этим дочерним элементам есть доступ по геттеру, например.
Триада создается путем создания нового контроллера, который всегда имеет в аргументах как минимум две ссылки: необходимые ему для работы модель и вью.
Есть только один контроллер, который создаем модель и вью — это MainController. В нем создаются MainModel и MainView. Больше ни в одном контроллере модели и вьюхи не создаются. Они подаются в конструктор (или метод-инициализатор).
Вот кстати, вопрос терминологии:является ли предложенная схема HMVC?Потому как картинка на вики намекает, что ветвление происходит внутри фасада.Хотя смысл в обоих подходах идентичен имхо.

Старый 03.03.2018, 18:52
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 76  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
А ты сам как думаешь?
__________________
Поймай яблоко 2!

Старый 03.03.2018, 20:00
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 77  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
думаю,что нет,но древовидность обоих заставляет сомневаться.

Старый 03.03.2018, 20:28
Zebestov вне форума Посмотреть профиль Отправить личное сообщение для Zebestov Посетить домашнюю страницу Zebestov Найти все сообщения от Zebestov
  № 78  
Ответить с цитированием
Zebestov
Lorem ipsum
 
Аватар для Zebestov

модератор форума
Регистрация: May 2001
Адрес: Одесса
Сообщений: 4,869
Записей в блоге: 4
Ты прав, есть существенное отличие. А древовидность (насколько это возможно) будет, пожалуй в любой реализации. Она призвана исключить горизонтальные связи.
__________________
Поймай яблоко 2!

Старый 03.03.2018, 22:54
dimarik вне форума Посмотреть профиль Отправить личное сообщение для dimarik Найти все сообщения от dimarik
  № 79  
Ответить с цитированием
dimarik
.
 
Аватар для dimarik

модератор форума
Регистрация: Sep 2003
Адрес: Москва
Сообщений: 4,630
Записей в блоге: 20
Цитата:
Сообщение от Appleman Посмотреть сообщение
Увидел тут мельком, речь зашла о ветвлении Моделей и Контроллеров. Я как раз до этого в своём проекте дошёл. Вот смотрите, есть игра, в ней у героя инвентарь. Его функционирование обеспечивается своей персональной триадой MVC, верно. Когда пользователь жмёт кнопку инвентаря, это событие слушает главная Вью и посылает событие в главный Контроллер. Главный Контроллер создаёт дочерний Контроллер инвентаря, который в свою очередь создаёт Модель и Вью инвентаря. Дальше все манипуляции обрабатываются дочерней MVC, и только событие на закрытие остаётся за главным Контроллером, который, получив его, свернёт всю лавочку и даст команду главной Модели продолжать.
Верно я всё написал?
Модель не нужно создавать при нажатии на кнопку инвентаря. Она просто всегда есть в полном объеме. Когда создаем (показаваем) инвентарь, то передаем вьюхе нужную часть модели (коллекцию предметов). Контроллером и вьюхой списка выступает data driven компонент, например, List.

Самое главное, что модель одна и она глобальна.
__________________
Воспитан в TimeZero. Работаю в Mail.ru.

Старый 22.03.2018, 10:32
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 80  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Друзья, вновь меня терзают сомнения в части MVC. Исходные такие.

В Модели в качестве идентификаторов у меня используются строковые значения. Они объявляются публичными статическими константами и затем присваиваются разным нечисловым свойствам. Возможно, это не оптимально с т.з. использования ресурсов, но очень удобно при отладке, так как такие штуки можно выводить в trace() и сразу понимать, что происходит. При этом я использую те же идентификаторы при обращении к классам пакета language, подбирающим слова и фразы на нужном языке. Это уже работа Вью.

Сомнение в том, не нарушаю ли я принципы MVC с таким подходом. Ведь получается, что Вью в таком виде как бы "привязана" к Модели - не функционально, но использованием общих "статических" справочных данных. В качестве альтернативы думаю создать что-то вроде класса-посредника, который загружал бы в Dictionary ID-шники, используемые в Модели, и выставлял бы им соответствия для использования во Вью. В таком подходе есть два выигрыша: во-первых, можно реализовывать отношения "один-ко-многим", когда для нескольких ID может быть одинаковый текст для вывода, и во-вторых, если потребуется какой-то идентификатор поменять (например, чтобы он лучше отражал суть), то будет точное понимание единственного места, где исправить, а не лезть напрямую в языковые xml в десять мест.
Ну а минус - в геморрое и усложнении, само собой.

Просьба прокомментировать. Спасибо.
__________________
Не сломано - не чини!

Создать новую тему Ответ Часовой пояс GMT +4, время: 19:49.
Быстрый переход
  « Предыдущая тема | Следующая тема »  

Теги
MVC , mvo , Проектирование
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


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


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