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

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

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

Я ПРОСТО ХОЧУ ИСПОЛЬЗОВАТЬ Фреймворк ENTITY КАК ИНСТРУМЕНТ ORM ДЛЯ ГЕНЕРИРОВАНИЯ КЛАССОВ. Я умею это делать. Что я не понимаю, так это

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

.net asp.net entity-framework orm data-access-layer
person AJM    schedule 27.05.2009    source источник

Ответы (6)


arrow_upward
9
arrow_downward

  1. Если вы практичны: да! Это позволит избежать работы с двойным отображением и потенциальных ошибок, вызванных двойным отображением. (Под двойным отображением я подразумеваю БД -> ORM и ORM -> Бизнес-логика).
  2. Используйте TransactionScope. Это лучший способ выполнять транзакцию, не беспокоясь о вложенных транзакциях.
person Eduardo Molteni    schedule 27.05.2009

arrow_upward
3
arrow_downward

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

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

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

person RobD    schedule 05.10.2009

arrow_upward
2
arrow_downward

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

person Ray    schedule 08.04.2010

arrow_upward
1
arrow_downward

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

person Abhay Naik    schedule 16.12.2010

arrow_upward
0
arrow_downward

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

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

person Binoj Antony    schedule 16.07.2009

arrow_upward
0
arrow_downward

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

person ckonig    schedule 08.06.2012