使用实体框架的分层架构在哪里创建上下文答案

【问题标题】：Layered Architecture using Entity framework where to create the context使用实体框架的分层架构在哪里创建上下文
【发布时间】：2010-11-09 11:47:01
【问题描述】：

我有 n 层架构，我有数据访问、业务服务和 UI 层。我正在使用 EF 4.0 和 MVC。现在的问题是在哪里创建上下文 1. 业务服务并将上下文传递给 Dataacess 并将 IQuerable 返回给 Data Acess 层。 2.直接在数据访问层使用上下文，将业务服务用作代理（基本上是从DataAecss和UI传递信息）。

创建“上下文”的最佳位置是什么。在线提供的所有示例都显示了在数据访问层中创建上下文。

感谢您的帮助！

【问题讨论】：

标签： asp.net-mvc entity-framework architecture entity

【解决方案1】：

同意@Robert Harvey 和@djacobson。

DAL 应该处理上下文，有一个例外：

如果您使用的是工作单元模式。

UoW 是上下文的包装器，因此当您“创建新的 UoW”时，实际上是在创建新的数据上下文。由于工作单元处理许多个存储库，它不能在 DAL 本身中实例化。

UoW（在 MVC 的上下文中）将被传递给控制器，控制器被传递给存储库，然后对其进行查询。

在这种情况下，您将在应用程序事件 (global.asax) 开始请求期间新建 UoW（以及上下文），并在请求结束时处理（最好使用 DI 容器）。

【讨论】：

+1 用于清晰、简洁地描述 UoW 模式。如需更多信息，请查看Martin Fowler's article 和 MSDN Mag 的"The Unit of Work Pattern & Persistence Ignorance"。
最好的做法是作为 UoW 或在数据访问中创建上下文
@Praneeth - 这取决于您的 DAL。我有非常简单的通用存储库（例如Repository<T>），基本上只有查找、添加、删除。因此我经常使用多个存储库，因此需要一个工作单元。如果您有一个存储库来处理所有逻辑/实体，则不需要 UoW。这是一个意见问题，以及您对 DDD 的遵守情况。

【解决方案2】：

正如@Robert Harvey 所说，这些示例具有正确的想法。 EF Context 特定于您的持久性机制（例如 SQL Server 数据库），因此属于数据访问层。

这种分层的目的是让您的持久性机制对其上方的层不可见，例如，您可以在不更改业务/UI 代码的情况下更改数据库提供程序。

【讨论】：

在Service层创建上下文并将上下文对象传递给DataAcess层并在那里进行实际的数据库工作是否有任何错误。