Дифференциация между доменом, моделью и сущностью по отношению к MVC

Ответ 1

Термины немного туманны, я согласен. Я бы использовал домен, чтобы обратиться к бизнес-области, с которой вы имеете дело. Как банковское дело или страхование, а что нет. Затем у вас есть модели домена. Это то, с чем вы работаете в этом бизнес-домене, например, для домена банковского обслуживания, у вас есть учетные записи, клиенты, переводы и т.д. Я бы использовал термин entity для ссылки на класс /POJO или на сохраненную/конкретную версию модели.

Что, вероятно, вас смущает, так это то, что в термине MVC модель представляет собой конкретную вещь, но она ссылается на модель данных, используемую для представления какой-либо презентации в веб-графическом интерфейсе, поэтому не допускайте ее смешения с приведенным выше объяснением.

Ответ 2

Термины, которые вы путаете, это: объекты домена "," сущности домена "и" объекты модели ". Хотя обычно они используются взаимозаменяемо, объекты домена и объект модели также могут быть экземплярами шаблона active record (в основном: объекты домена с добавленной логикой хранения).

В обычном доменном объекте логика хранения отсутствует. Он обрабатывается data mappers.

Термин "объекты модели" поступает из книг Фаулера (подробнее читайте PoEAA), и IMHO является частью путаницы MVC, потому что вся модель представляет собой прикладной уровень (MVC состоит из него и уровня представления), который содержит те "объекты модели", которые обычно рассматриваются services (на этом изображении слой модели - все три концентрических круга вместе).

Я предпочитаю вместо этого использовать термин "доменный объект".

Термин "объект домена" (или "объект сущности" ) обычно используется, когда автор подразумевает, что объект является прямым представлением структуры хранилища (чаще - таблица базы данных). Это также почти всегда реализация активной записи.

_{P.S.: в некоторых статьях вы также увидите термин "модели" (множественное число). Он обычно не имеет прямого отношения к шаблону проектирования MVC, потому что он говорит о Rails-подобной архитектуре, где "модели" - это просто активные записи, которые получают непосредственно контролируемый/созданный контроллер.}

.. не уверен, что это вас больше смущает

Ответ 3

Для записи. В практических целях домен и модель одинаковы, а объект также является объектом/объектом, который будет использоваться для хранения в базе данных.

Некоторые люди пытаются объяснить такие темы, но ни один из них не является каноном.

Разница в том, что в мире Java Domain больше используется, в то время как в мире С# используется модель (и MS поощряет его использование), но ее справедливое соглашение, и вы можете использовать оба.

В то же время концепция Value Object (VO) используется людьми Java, а DTO для людей С#, даже если обе они практически одинаковы. Также POJO (Java) vs POCO (С#), пакеты (Java) vs NameSpace (С#), Setter и Getter (Java) vs Encapsulation (С#)

Ответ 4

Оба домена и модели являются классами. Как используется класс, отличает ли он его классифицирование и размещение в папке домена или модели. Если класс будет использоваться ТОЛЬКО в представлении, поместите его в папку модели. Если класс сопоставляется с объектом базы данных, поместите его в папку домена.

Ответ 5

Вы можете сказать, что Domain являются классами таблиц базы данных, внешних объектов службы и т.д. Поэтому, если вы разрабатываете проект и создаете домен домена, вы помещаете в него объекты базы данных. Подобным классом является Entity и может быть классом Customer со своими свойствами. Почему это сущность, а не POCO? Это из-за его использования. Содержимое Entity может быть прочитано/записано в базу данных. Из-за того, что вы считаете, что это сущность, которую вы знаете, где вы можете ее использовать. По знанию вы знаете его Сущность, вы не ставите его на свое имя. Теперь для модели. Если вы используете этот Клиент, могут быть свойства, которые вы не хотите использовать. Клиент может быть действительно простым Entity. Но скажем, у вас сложный. Один из них читается из веб-службы с таким количеством свойств, которые вы не будете использовать. Затем вы можете прочитать это Entity (= может быть отлично сделано с сериализацией) и использовать этот Entity для создания модели. Если этот объект используется для копирования данных в Модель, мы также говорим о объекте преобразования данных (DTO), иногда вы записываете его как CustomerDTO. Для копирования данных из объекта в модель вы можете использовать инструменты сопоставления. Затем имя объекта изменяется на CustomerModel. Затем вы используете модель расширения, потому что иначе вы не будете знать, что к чему. В этой CustomerModel может быть много других свойств. Некоторые из этих свойств могут быть свойствами процесса (они не должны поступать из объекта Customer). Содержимое этих свойств принадлежит другим службам. Простым, который может быть создан от Клиента, является Fullname, он состоит из нескольких свойств Клиента. Поэтому заполнение CustomerModel может быть сложным. Мы можем поместить код для заполнения CustomerModel в так называемом Factory и вызвать этот CustomerFactory.