Объекты ORM и сущности домена в Entity Framework 6.0

Я наткнулся на следующие две статьи Первый и Второй, в котором автор заявляет, что сущности ORM и доменные сущности не должны смешиваться.

Я сталкиваюсь именно с этой проблемой на данный момент, когда я кодирую EF 6.0 с использованием подхода Code First. Я использую классы POCO как объекты в EF, а также объекты моего домена/бизнеса. Но я часто нахожусь в ситуации, когда я определяю свойство как общедоступное или навигационное свойство как виртуальное только потому, что EF Framework заставляет меня это делать.

Я не знаю, что взять в качестве нижней строки двух статей? Должен ли я действительно создать, например, класс CustomerEF для инфраструктуры сущности и CustomerD для моего домена. Затем создайте репозиторий, который использует CustomerD, сопоставляет его с CustomerEF и выполняет некоторые запросы, а не отображает полученный CustomerEF в CustomerD. Я думал, что EF все касается сопоставления объектов домена с данными.

Поэтому, пожалуйста, дайте мне несколько советов. Могу ли я упустить важную вещь, которую EF может мне предоставить? Или это проблема, которая не может быть полностью решена EF? В последнем случае, что является хорошим способом решения этой проблемы?

Ответ 1

Я согласен с общей идеей этих сообщений. Модель класса ORM является частью уровня доступа к данным в первую очередь (даже если она состоит из так называемых POCOs). Если возникает конфликт интересов между настойчивостью и деловой логикой (или любой другой проблемой), решения всегда должны приниматься в пользу настойчивости.

Однако, как разработчики программного обеспечения, мы всегда должны балансировать между пуризмом и прагматизмом. Можно ли использовать модель сохранения в качестве модели домена, зависит от ряда факторов:

Размер/согласованность команды разработчиков. Когда вся команда знает, что свойства могут быть общедоступными только из-за требований ORM, но не должны устанавливаться повсюду, это может быть не очень важно. Если все знают (и подчиняются), что свойство ID не должно использоваться в бизнес-логике, идентификация может быть не большой. Разбросанной, неопытной или недисциплинированной команде может потребоваться более строгая сегрегация кода.
Совпадение между проблемами бизнес-логики и проблемами сохранения. Объектно-ориентированный дизайн процветает, когда модель класса придерживается принципов SOLID. Но эти принципы не всегда противоречат проблемам сохранения. Я имею в виду, что, хотя проблемы различны, в конечном итоге их результирующие требования могут быть весьма схожими. Например, обе проблемы могут требовать действительного состояния объекта и правильных ассоциаций.

Однако могут быть случаи использования, когда объекты временно должны находиться в состоянии, которое абсолютно не должно храниться. Это может быть причиной для работы с выделенными классами домена. Другая причина может заключаться в том, что модель сущности просто не может выполнить лучшую сегментацию обязанностей. Например, бизнес-процесс "черный список" может потребовать данных, которые разбросаны по многим объектам объектов, которые должны быть разработаны новыми классами доменов, которые могут инкапсулировать данные и методы, работающие над ними. Другими словами: делать это сущностями будет нарушать принцип Tell Do not Ask.
Необходимость расслоения. Например, если уровень доступа к данным предназначен для разных поставщиков баз данных, он может состоять из взаимозаменяемых частей, специфичных для поставщиков (например, для учета тонких различий в типах данных между серверами Oracle и Sql или для использования специфических для поставщика функций). Использование модели персистентности в качестве модели домена, вероятно, привело бы к снижению специфических для поставщика реализаций в бизнес-логике. Это было бы очень плохо. Там уровень доступа к данным должен быть именно этим, слоем.
(Очень тривиально) Объем данных. Создание объектов требует времени и ресурсов. Когда в бизнес-случае задействованы "многие" объекты, может быть слишком дорого строить как объекты объекта, так и объекты домена.

И еще, несомненно.

Поэтому я всегда старался быть прагматиком. Если классы сущностей выполняют достойную работу, идите на это. Если несоответствие слишком велико, создайте бизнес-домен для соответствующих частей бизнес-логики. Я бы не рабски придерживался (любого) шаблона дизайна только потому, что это хороший образец. Вопреки тому, что сказано в сообщении, для планирования модели сущности требуется бизнес-модель. Когда вы обнаружите, что создаете мириады бизнес-классов, которые почти идентичны классам сущностей, время переосмыслить то, что вы делаете.