Я серьезно смущен понятием 'Модели' в MVC. Большинство платформ, которые существуют сегодня, помещает Модель между Контроллером и базой данных, и Модель почти действует как уровень абстракции базы данных. Понятие 'Толстого Образцового Тощего Контроллера' потеряно, поскольку Контроллер начинает делать все больше логики.
В DDD существует также понятие Доменного Объекта, который имеет уникальные идентификационные данные к нему. Насколько я понимаю пользователь является хорошим примером Объекта (уникальный идентификатор пользователя, например). Объект имеет жизненный цикл - это - значения, может измениться на всем протяжении действия - и затем это сохраняется или отбрасывается.
Объект, который я описываю выше, - то, что я думал, что Модель, как предполагалось, была в MVC? Насколько неосновной я?
Для создания помех вещам больше Вы добавляете другие шаблоны, такие как шаблон Репозитория (возможно, помещающий Сервис там). Довольно ясно, как Репозиторий взаимодействовал бы с Объектом - как делает это с Моделью?
Контроллеры могут иметь многоуровневые модели, который заставляет его казаться, что Модель является меньше "таблицей базы данных", чем это - уникальный Объект.
ОБНОВЛЕНИЕ: В этом сообщении Модель описана как что-то со знанием, и это может быть исключительно или набор объектов. Таким образом, это, больше кажутся, что Объект и Модель являются более или менее тем же. Модель является всем сроком затрагивания, где Объект более конкретен. Объектом Значения была бы Модель также. По крайней мере, с точки зрения MVC. Возможно???
Так, в очень грубых терминах, который лучше?
Никакая "Модель" действительно...
class MyController {
public function index() {
$repo = new PostRepository();
$posts = $repo->findAllByDateRange('within 30 days');
foreach($posts as $post) {
echo $post->Author;
}
}
}
Или это, которое имеет Модель как ДАО?
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;
}
}
}
Оба тех примера даже не сделали то, что я описывал выше. Я ясно потерян. Какой-либо вход?
Сущность
означает объект, который представляет собой отдельный элемент, с которым работает бизнес-логика, в частности те, которые имеют какую-либо идентичность.
Таким образом, многие люди называют объекты с отображением ORM сущностями.
Некоторые называют « объект » классом, экземпляр которого представляет одну строку в базе данных.
Некоторые другие люди предпочитают называть «сущностями» только те из этих классов, которые также содержат бизнес-правила, проверку и общее поведение, а остальные называют « объектами передачи данных ».
A Модель
не имеет прямого отношения к пользовательскому интерфейсу (= View
) и потоку управления (= Контроллер
) приложение, а скорее о том, как работает доступ к данным и основная абстракция данных приложения.
В принципе, все может быть моделью, которая соответствует вышеизложенному.
Вы можете использовать сущности в качестве моделей в MVC. Они означают две разные вещи, но одни и те же классы могут называться обоими.
Примеры
Customer
в значительной степени является сущностью (обычно), и вы также используете его как часть доступа к данным в своем приложении. В данном случае это и сущность, и модель. Репозиторий
может быть частью модели, но явно не является объектом. Ваш пример
Что касается ваших примеров кода, я бы предпочел первый.
Модель - это класс, который используется как средство абстрагирования данных приложения, а не класс, имя которого имеет суффикс «Модель». Многие считают последнее вредоносным ПО.
Вы можете в значительной степени рассматривать свой класс Repository как часть вашей модели, даже если его имя не имеет суффикса «Model».
Я бы добавил к этому тот факт, что с первым также легче работать, и для других людей, которым позже, возможно, придется разбираться в вашем коде, его легче понять.
хотя речь идет именно о Ruby on Rails, те же принципы и информация по-прежнему применимы, поскольку речь идет о MVC и DDD.
http://blog.scottbellware.com/2010/06/no-domain-driven-design-in-rails.html
Простое решение с использованием службы и сбора:
<?php
class MyController {
public function index() {
$postService = ServiceContainer::get('Post');
$postCollection = $postService->findAllByDateRange('within 30 days');
while($postCollection->getNext()) {
echo $postCollection->current()->getAuthor();
}
}
}
РЕДАКТИРОВАТЬ:
Модель (класс) - это простое представление схемы сущности. Модель (объект) представляет собой единое целое. Сервис работает с моделями и предоставляет конкретные данные контроллеру s . Никакой контроллер не имеет модели. Модели стоят отдельно.
С другой стороны, картографы сопоставляют модели с постоянными уровнями (например, базы данных, сторонние серверы и т. Д.).
"Модель" в вашем приложении - это бит, который хранит ваши данные. Сущность" в доменно-ориентированном проектировании - это, если я правильно помню, модель с идентичностью. То есть, сущность - это модель, которая обычно непосредственно соответствует "физическому" элементу в базе данных или файле. Я считаю, что DDD определяет два типа моделей, один из которых - сущность, а другой - значение, которое является просто моделью без идентичности.
Модель репозитория - это просто тип индексированной коллекции моделей/сущностей. Так, например, если вашему коду нужен заказ №13, он сначала запросит его в хранилище, а если не сможет получить его оттуда, то пойдет и возьмет его откуда угодно. По сути, это кэш первого уровня, если хотите. Нет никакой разницы в том, как он действует с моделью и как он действует с сущностью, но поскольку идея хранилища заключается в том, чтобы иметь возможность получать модели, используя их идентификаторы, с точки зрения DDD, в хранилище будут допускаться только сущности.