У меня два контроллера: один для просмотра одного игрока и один для просмотра команды. В настоящее время у меня есть это, где команда состоит из группы моделей проигрывателей.
Я новичок в MVC, и из всего, что я читал, я много не видел в моделях, состоящих из других моделей. Есть ли альтернативный способ приблизиться к этой ситуации или это похоже на довольно стандартную реализацию?
Модель не является «вещью» или «классом». Это слой.
И модельный слой состоит из нескольких элементов. Двумя наиболее важными типами являются объекты домена [1] [2] и объект доступа к данным (обычно реализуемый как шаблон DataMappers [1] [2] ). Третий тип структур будет сервисом, но я попытаюсь сохранить его простым.
Объекты домена – это то, где бизнес-логика поддерживает слой модели. И не только возможно иметь объект домена, содержащий другие объекты домена, это, как правило, лучший способ пойти. Вот небольшой пример:
$group = $this->modelFactory->buildObject('group'); $mapper = $this->modelFactory->buildMapper('group'); $group->setName('wheel'); $mapper->fetch($group); $user = $this->modelFactory->buildObject('user'); $user->setName('foobar'); $user->setHomeDir('/home/user'); $user->setShell('/bin/csh'); $group->addUser( $user ); $mapper->store($group); Вам также может быть полезно прочитать эту тему .
Да, тысячу раз да! Именно так работают Framework Injection Dependency (например, Robotlegs и Swiz). У них есть Инжектор, который действует как комбинационная Модель и Фабрика, чтобы предоставить только бит, необходимый для просмотра или команды (по большей части у них также нет идеи большого монолитного контроллера).
Конечно! Это объектно-ориентированное программирование!
Команда – это, естественно, коллекция игроков с некоторыми дополнительными данными (имя, менеджер и т. Д.). Я думаю, это должно быть хорошо.
Учитывая ваш вопрос, вы имеете в виду модель как единый объект (например, модель пользователя). Если вы возьмете единственную модель и забудете о приложении, модель будет буквально сформулировать это слово, концептуальную модель.
Модель домена при решении проблем и разработке программного обеспечения может рассматриваться как концептуальная модель интересующей области (часто называемой проблемной областью), которая описывает различные объекты, их атрибуты, роли и отношения, а также ограничения, которые определяют целостность элементов модели, входящих в эту проблемную область.
http://en.wikipedia.org/wiki/Domain_model
Ментальная модель фиксирует идеи в проблемной области, а концептуальная модель представляет собой понятия (сущности) и отношения между ними. Концептуальная модель в области информатики также известна как модель домена.
http://en.wikipedia.org/wiki/Conceptual_model_(computer_science )
Отвечая на ваш вопрос: ваша модель домена будет состоять из сущностей с ассоциациями между ними, другими словами, одна отдельная сущность может иметь состав, содержащий коллекцию других объектов (ассоциаций или агрегатов).
Модель домена создает сеть взаимосвязанных объектов, где каждый объект представляет собой значимого человека, размером с корпорацию или размером с одну строчку в форме заказа.
http://martinfowler.com/eaaCatalog/domainModel.html
Чтобы он превратился в слой чего-то другого, вам нужно перейти от OOA (Object-oriented Analyzes) к OOD (объектно-ориентированный дизайн).
Объектно-ориентированный анализ (OOA) применяет методы объектного моделирования для анализа функциональных требований к системе. Объектно-ориентированный дизайн (OOD) разрабатывает модели анализа для получения спецификаций реализации. OOA фокусируется на том, что делает система, OOD на том, как система это делает.
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
Итак, имейте в виду два значения ключевого слова «model». Это может быть ментальная модель проблемной области или слой вашего приложения, описывающий, как будет реализована техническая реализация ментальной модели.