分层体系结构中的ASP.NET和实体框架 - 仅使用ORM的实体框架

Question

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

我不希望业务层必须知道有关如何实现数据访问层的任何内容，而且我不打算使用EntityDataSource或类似的东西将实体直接绑定到数据控件。 （所以存储库模式方案）

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

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

Answer 1

1. 如果你很实际：是的！它将避免双重映射工作和双映射生成的潜在错误。 （通过双重映射，我的意思是DB - ＆gt; ORM和ORM - ＆gt;业务逻辑）。
2. 使用TransactionScope。这是进行事务处理的最佳方式，而不必担心嵌套事务。

Answer 2

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

你自己做到了这个成功吗？

Answer 6

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