我有一个使用分层体系结构如ASP.NET应用程序presentation层，业务逻辑层，数据访问层。

我不希望将业务层必须了解数据访问层是如何实现的，我不希望绑定实体的直接使用EntityDataSource或类似的东西一个数据控制任何东西。 （所以一个存储库模式方案）

我只是希望使用实体框架作为一个ORM工具生成的类。我知道如何做到这一点。什么我不清楚是

是不是最好通过应用程序来传播这些类了，因此业务逻辑层会处理由实体框架直接创建的局部类？ （例如，如果我有一个客户表中的SQL，实体FW将创建这有可能在我的应用程序的所有层直接使用的客户类） 如何管理事务的​​支持，如果我BLL呼吁几种不同的实体类，但希望把它当作一个事务 解决方案 如果您是可行的：是的！这将避免您双击映射工作和双映射所产生的潜在的错误。 （通过双映射我的意思是DB - > ORM和ORM - >业务逻辑）。 使用TransactionScope.这是做交易，而不必担心嵌套事务的最佳途径。

I have an ASP.NET application that uses a layered architecture e.g. presentation layer, business logic layer, data access layer.

I don't want to the business layer to have to know anything about how the data access layer is implemented and I'm not looking to bind the Entity's directly to a data control using the EntityDataSource or anything like that. (so a repository pattern scenario)

I'M JUST LOOKING TO USE THE ENTITY FRAMEWORK AS AN ORM TOOL TO GENERATE CLASSES. I know how to do this. What I'm not clear on is

Is it advisable to propagate these classes up through the application so the business logic layer would be dealing with the partial classes created directly by the entity framework? (for instance if I have a customer table in sql, the entity fw would created a customer class which could potentially be used directly in all layers of my app) How to manage transaction support if my BLL is calling several different entity classes but wants to treat it as one transaction

解决方案

If you are practical: Yes! It will avoid you double mapping work and the potential errors generated by the double mapping. (By double mapping I mean DB -> ORM and ORM -> Business logic). Use TransactionScope. It's the best way to do transaction without worrying about nested transactions.