Я серьезно запутался в концепции «Модели» в MVC. Большинство существующих в настоящее время фреймворков помещают модель между контроллером и базой данных, а модель почти действует как слой абстракции базы данных. Концепция «Fat Model Skinny Controller» теряется, поскольку контроллер начинает все больше и больше логики.
В DDD существует также концепция Domain Entity, которая имеет уникальную идентификацию. Насколько я понимаю, пользователь – хороший пример Entity (например, уникальный идентификатор пользователя). У объекта есть жизненный цикл – его значения могут меняться в течение всего действия, а затем он сохраняется или отбрасывается.
Сущность, которую я описываю выше, – это то, что я думал, что модель должна быть в MVC? Как я не в базе?
Чтобы загромождать вещи больше, вы бросаете другие шаблоны, такие как шаблон хранилища (возможно, размещая там Сервис). Довольно ясно, как Repository будет взаимодействовать с Entity – как это происходит с моделью?
Контроллеры могут иметь несколько моделей, что делает его похожим на модель, которая меньше «таблица базы данных», чем уникальная сущность.
ОБНОВЛЕНИЕ: в этом посте Модель описывается как нечто, обладающее знаниями, и может быть единственной или совокупностью объектов. Так что это больше похоже на сущность и модель, более или менее одинаковые. Модель является всеохватывающим термином, где сущность более конкретна. Объектом Value также будет модель. По крайней мере, с точки зрения MVC. Может быть???
Итак, в очень грубых условиях, что лучше?
Нет «модели» действительно …
class MyController { public function index() { $repo = new PostRepository(); $posts = $repo->findAllByDateRange('within 30 days'); foreach($posts as $post) { echo $post->Author; } } } Или это, у которого есть Модель как DAO?
class MyController { public function index() { $model = new PostModel(); // maybe this returns a PostRepository? $posts = $model->findAllByDateRange('within 30 days'); while($posts->getNext()) { echo $posts->Post->Author; } } }
Оба этих примера даже не делали то, что я описывал выше. Я явно потерян. Любой вход?
Entity означает объект, который представляет собой единый элемент, с которым работает бизнес-логика, а точнее те, которые имеют определенную личность.
Таким образом, многие люди ссылаются на ORM-сопоставленные объекты как объекты.
Некоторые называют « сущность » классу, экземпляр которого представляет собой одну строку в базе данных.
Некоторые другие люди предпочитают называть только те из этих классов, что и «сущность», которые также содержат бизнес-правила, валидацию и общее поведение, а другие называют « объектами передачи данных ».
Model – это то, что напрямую не связано с UI (= View ) и потоком управления (= Controller ) приложения, а скорее о том, как работает доступ к данным и основная абстракция данных приложения.
В принципе, все может быть моделью, которая соответствует вышеизложенному.
Вы можете использовать объекты в качестве моделей в MVC. Они означают две разные вещи, но одни и те же классы можно назвать обоими.
Примеры
Customer – это, скорее всего, сущность (обычно), и вы также используете ее как часть доступа к данным в своем приложении. В этом случае это как объект, так и модель. Repository может быть частью Модели, но это явно не сущность. Ваш пример
Что касается ваших примеров кода, я бы предпочел первый.
Модель – это класс, который используется как средство абстракции данных приложения, а не класс, который имеет имя, суффикс с «Моделью». Многие люди рассматривают последнее вирусы.
Вы можете в значительной степени рассматривать свой класс репозитория как часть вашей модели, даже если его имя не суффикс с «Моделью».
Я бы добавил, что тот факт, что также легче работать с первым, и для других людей, которым позже может понадобиться понять ваш код, легче понять.
Все ответы – это тяжелый mashup разных вещей и просто неправильный.
Модель в DDD очень похожа на модель в реальном мире: упрощение и абстракция чего-то. Не меньше и не больше. Он не имеет ничего общего с данными, объектами или чем-то еще. Это просто понятие доменной части. А также в каждом сложном домене всегда существует более одной модели, например Trading, Invoicing, Logistics.
Сущность не является «моделью с идентичностью», а просто объектом с личностью.
Репозиторий – это не только кеш 1-го уровня, но и часть домена. Он создает иллюзию объектов в памяти и отвечает за выборку агрегатов (а не сущностей!) Из любого места и их сохранение, т.е. сохранение жизненного цикла объектов.
Если вы говорите о концепциях DDD, сначала исправьте свои знания, прочитав основы. Как здесь ThinkDDD .
«Модель» в вашем приложении – это бит, который хранит ваши данные. «Сущность» в доменном дизайне, если я правильно помню, представляет собой модель с идентификатором. Иными словами, сущность – это модель, которая обычно соответствует непосредственно «физическому» элементу в базе данных или файле. Я считаю, что DDD определяет два типа моделей, один из которых является сущностью, а другой – значением, которое является просто моделью без и идентичности.
Шаблон репозитория – это всего лишь тип индексированного набора моделей / сущностей. Так, например, если ваш код хочет заказать номер 13, он сначала спросит у него репозиторий, и если он не сможет его получить, он отправится и доставит его откуда угодно. Это в основном кеш уровня 1, если хотите. Нет никакой разницы в том, как она действует с моделью, и как она действует с сущностью, но поскольку идея репозитория заключается в возможности извлечения моделей с использованием их идентификаторов, с точки зрения DDD, в репозиторий.
Простое решение, использующее сервис и сбор:
<?php class MyController { public function index() { $postService = ServiceContainer::get('Post'); $postCollection = $postService->findAllByDateRange('within 30 days'); while($postCollection->getNext()) { echo $postCollection->current()->getAuthor(); } } }
EDIT: модель (класс) представляет собой простое представление схемы сущности. Модель (объект) – это единое целое. Служба работает с моделями и предоставляет конкретные данные контроллеру. Никакой контроллер не имеет модели. Модели автономны.
С другой стороны, карты отображают модели в уровни устойчивости (например, базы данных, сторонние бэкэнд и т. Д.).
в то время как это особенно касается Ruby on Rails, те же принципы и информация все еще применяются, поскольку обсуждение происходит вокруг MVC и DDD.
http://blog.scottbellware.com/2010/06/no-domain-driven-design-in-rails.html