分层架构中的 ASP.NET 和实体框架 - 仅将实体框架用于 ORM答案

【问题标题】：ASP.NET and Entity Framework in Layered Architecture - using Entity Framework for ORM only分层架构中的 ASP.NET 和实体框架 - 仅将实体框架用于 ORM
【发布时间】：2010-10-29 06:29:14
【问题描述】：

我有一个使用分层架构的 ASP.NET 应用程序，例如表示层、业务逻辑层、数据访问层。

我不想让业务层知道数据访问层是如何实现的，我也不希望使用 EntityDataSource 或类似的东西将实体直接绑定到数据控件。（所以是存储库模式场景）

我只是希望将实体框架用作 ORM 工具来生成类。我知道该怎么做。我不清楚的是

是否建议通过应用程序向上传播这些类，以便业务逻辑层处理由实体框架直接创建的部分类？（例如，如果我在 sql 中有一个客户表，实体 fw 将创建一个客户类，它可能会直接在我的应用程序的所有层中使用）
如果我的 BLL 正在调用多个不同的实体类但想将其视为一个事务，如何管理事务支持

【问题讨论】：

标签： .net asp.net entity-framework orm data-access-layer

【解决方案1】：

如果你是实际的：是的！它将避免您进行双重映射工作以及双重映射产生的潜在错误。（通过双重映射，我的意思是 DB -> ORM 和 ORM -> 业务逻辑）。
使用TransactionScope。这是进行事务而不用担心嵌套事务的最佳方式。

【讨论】：

【解决方案2】：

我怀疑这可能是您问题的答案：

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

该工具生成的类没有您可以跨层传递的实体框架依赖项。

【讨论】：

【解决方案3】：

另一种方法是使用映射器类，将 EF 纯粹用作数据访问并使用仅在 DAL 内生成的类 EF，然后通过映射器将这些 DAL 对象映射到 BLL 的对象。对我们来说效果很好。

【讨论】：

【解决方案4】：

现在使用新的 EF4，您还可以使用 POCO 类，从而消除了在层之间映射实体的额外负担。在我们的应用程序中，我们使用了 EF4 并在应用程序中使用了业务实体，而不是需要视图模型的视图。它显着提升了性能。

【讨论】：

【解决方案5】：

不使用实体框架，但我试图创建一个示例，其中两个插入存储过程在数据访问层中分别执行（使用数据访问应用程序块 3.1），包装在 Service/BLL 中的 TransactionScope 上下文中，它没有工作。一项插入通过，另一项失败，数据已提交。

你自己做这件事有没有成功？

【讨论】：

【解决方案6】：

即使您使用生成的 POCO 类，就像其他操作所建议的那样，您仍然必须保持对实体框架的某种依赖性：您发送到 DbContext / ObjectContext 的查询。因此，您应该考虑将查询封装在存储库中。

【讨论】：