ASP.NET и Entity Framework в многоуровневой архитектуре - используя Entity Framework только для ORM - PullRequest
Новая
       34

ASP.NET и Entity Framework в многоуровневой архитектуре - используя Entity Framework только для ORM

30 голосов
/ 27 мая 2009

У меня есть приложение ASP.NET, которое использует многоуровневую архитектуру, например уровень представления, уровень бизнес-логики, уровень доступа к данным.

Я не хочу, чтобы бизнес-уровень знал что-либо о том, как реализован уровень доступа к данным, и я не собираюсь привязывать Entity непосредственно к элементу управления данными, используя EntityDataSource или что-то подобное. (так что сценарий шаблона репозитория)

Я ПРОСТО НАЖИМАЮ, ЧТОБЫ ИСПОЛЬЗОВАТЬ ЭНЕРГЕТИЧЕСКУЮ РАМКУ В КАЧЕСТВЕ ИНСТРУМЕНТА ОРМА ДЛЯ СОЗДАНИЯ КЛАССОВ. Я знаю, как это сделать. То, что мне не ясно, это

  1. Желательно ли распространять эти классы через приложение, чтобы уровень бизнес-логики работал с частичными классами, созданными непосредственно структурой сущностей? (например, если у меня есть таблица клиентов в sql, сущность fw создаст класс клиентов, который потенциально может использоваться непосредственно во всех слоях моего приложения)
  2. Как управлять поддержкой транзакций, если моя BLL вызывает несколько разных классов сущностей, но хочет рассматривать ее как одну транзакцию

Ответы [ 6 ]

9 голосов
/ 27 мая 2009
  1. Если вы практичны: да! Это позволит вам избежать двойного картирования и потенциальных ошибок, вызванных двойным отображением. (Под двойным отображением я имею в виду DB -> ORM и ORM -> Бизнес-логика).
  2. Использовать TransactionScope . Это лучший способ выполнить транзакцию, не беспокоясь о вложенных транзакциях.
3 голосов
/ 05 октября 2009

Я подозреваю, что это может быть ответом на вашу проблему:

http://code.msdn.microsoft.com/EFPocoAdapter/Release/ProjectReleases.aspx?ReleaseId=1580

Инструмент генерирует классы, которые не зависят от структуры сущностей и могут передаваться по уровням.

2 голосов
/ 08 апреля 2010

Другой способ сделать это - использовать классы сопоставления, использовать EF исключительно для доступа к данным и использовать классы EF, созданные только в DAL, а затем сопоставить эти объекты DAL с объектами вашего BLL с помощью преобразователей. У нас работает нормально.

1 голос
/ 16 декабря 2010

Теперь с новым EF4 вы также можете использовать классы POCO, таким образом снимая дополнительную нагрузку с отображения объектов между слоями. В нашем приложении мы использовали EF4 и бизнес-сущности во всем приложении, кроме представления, для которого требовалась модель представления. Это дало значительный прирост производительности.

0 голосов
/ 08 июня 2012

Даже если вы используете сгенерированные классы POCO, как предлагают другие операторы, вам все равно придется поддерживать определенную зависимость от структуры сущности: запросы, которые вы отправляете в ваш DbContext / ObjectContext. Поэтому вам следует рассмотреть возможность инкапсуляции запросов в репозитории.

0 голосов
/ 16 июля 2009

Не с сущностной структурой, но я пытался создать пример с двумя хранимыми процедурами вставки, выполняемыми отдельно на уровне доступа к данным (с использованием блока 3.1 приложения доступа к данным), заключенными в контекст TransactionScope в Service / BLL, но не Работа. Одна вставка прошла, другая не удалась, и данные были переданы.

Удалось ли вам сделать это самостоятельно?

...