доменный дизайн с использованием Entity Framework 4 - PullRequest
Новая
       32

доменный дизайн с использованием Entity Framework 4

5 голосов
/ 20 октября 2011

Я прочитал несколько постов, в которых обсуждается, как использовать сущности EF в качестве бизнес-объектов

Использование сущностей Entity Framework в качестве бизнес-объектов?

но разве это не делает проект бизнес-объектов зависимым от модели данных? Это правильная практика для корпоративных приложений? Разве домен и модель данных не должны быть независимыми, а изменения в одной не должны влиять на другую? если я решу их разделить, то нужно ли создавать еще один слой для заполнения бизнес-объектов из сущностей EF? если у меня есть как пользовательские бизнес-объекты, так и объекты EF, какой из них используется для передачи данных между слоями (включая весь путь до пользовательского интерфейса)? Есть ли архитектурный образец для этого? Было бы полезно, если бы есть пример приложения, демонстрирующего эти концепции (не просто демонстрационная версия, подходящая для использования в корпоративном приложении).

Эта ссылка ясно объясняет проблему

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx#id0420099

Ответы [ 2 ]

9 голосов
/ 20 октября 2011

Это зависит от того, насколько слабой связью вы хотите / должны быть.

Возьмем, к примеру, приложение WPF / MVVM, которое общается со службой через WCF и сохраняет данные с помощью EF. Тогда, если вы пройдете весь путь, у вас будет следующее:

На клиенте:

  • View
  • ViewModel
  • Модель

Между клиентом и сервером:

  • Объект передачи данных

На сервере:

  • Бизнес-объекты
  • EF Entities

С отображением кода между каждым слоем. Это может быть много работы и дублирования между объектами. Это может быть не практично, слишком много слоев. Мы пытаемся объединить их, где это возможно, например, может ли DTO быть моделью?

Используя частичные классы, вы можете добавить функциональность к классам EF, которая не будет удалена при регенерации модели. Таким образом, вы могли бы использовать его в качестве вашего бизнеса.

Я бы не использовал их в качестве DTO по следующим причинам:

  • Изменение в базе данных может повлиять на многие системы
  • Ваши клиенты могут использовать не MS клиенты
4 голосов
/ 20 октября 2011

Это спорный вопрос, и он полностью зависит от как далеко вы хотите создать свое приложение ...

Существуют сильные мнения, которые поддерживают использование DTO / POCO (Plain Old CLR Obects), и действительно, вы можете использовать EF для генерации DTO для достижения такой цели . Это своего рода Rolls-Royce в отношении архитектуры ... Основное преимущество заключается в том, что вы отделяете свою бизнес-логику от доступа к данным, а затем теоретически можете переключиться на новейшую и лучшую ORM в будущее. Недостатком является то, что (как вы сказали в своем вопросе) вам нужен картографический сервис для преобразования между двумя уровнями, а также тот факт, что вы по сути получаете несколько классов для представления одного и того же фрагмента данных.

Как правило, использование DTO / POCO не рекомендуется для малого / среднего из-за добавленного увеличения кода, однако для более крупных проектов разделение проблем может быть выгодным, несмотря на добавленное кодирование томов. Корпоративное приложение или нет, я думаю, вам нужно учитывать реальность того, хотите ли вы когда-нибудь переключить свой инструмент ORM (то есть EF).

Кроме того, я думаю, что сгенерированные EF классы уже достаточно просты и скрывают большую часть кода доступа к данным в «.designer.cs» и даже большую его часть с декларативными атрибутами.

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

Ознакомьтесь с этой серией статей для получения дополнительной информации.

...