在我的 ASP.NET 应用程序中，我想通过数据访问层使用实体 framweok 来实现，这样我就可以将它用作 ORM 工具。但我不希望应用程序的其余部分关心我正在使用它或被任何特定实体框架所污染。
我似乎找不到任何人专门在他们的数据访问层中使用实体框架，所以我很想看到人们有这种/经验的任何在线示例。
【问题讨论】：
标签： .net asp.net entity-framework
http://ayende.com/Blog/archive/2007/06/08/Rhino-Commons-RepositoryltTgt-and-Unit-Of-Work.aspx
看上面的例子，你可以使用存储库模式以同样的方式实现实体框架
【讨论】：
您可以使用类似于 ScottGu 在 NerdDinner 系列中使用 Linq 所做的存储库模式来抽象实体框架。
【讨论】：
这是我刚刚使用 EF v4 开发的受 DDD 启发的架构，它使用 Unity IoC 注入 EF 存储库，希望对您有所帮助
【讨论】：
我在最近的两个项目中使用 Entity Framework 作为数据访问。这些是大型（至少对我而言）项目，有数百个表，5-15 名开发人员持续一年以上。
在这两个项目中，我们的服务层都有一个 WCF 接口。我们不想在 WCF 合同中使用实体框架对象。因此，我们创建了数据传输对象，并在 DTO 和实体框架对象之间进行映射。
这打破了依赖关系并保持合约尽可能稳定，但会产生一些额外的工作。
根据您的时间范围，我会这样做或在下一个版本中使用 POCO 对象，正如 Kieth 提到的那样。
【讨论】：
EF 或任何其他 ORM（即 NHibernate）不会取代您的数据访问层。相反，ORM 是从 DAL 到数据源的抽象层。
不要误以为 EF 取消了 DAL。 EF 只是另一个数据源框架。但是，在最佳实践中，您仍希望将所有访问（读/写）抽象并集中在一个通用 DAL 中。
这是我所说的一个完美的例子。假设您必须在其中一个用例中删除给定用户。但是，在删除用户时，您可能希望删除与已删除用户关联的其他记录以避免孤立记录（老实说，我会为此使用存储过程）。现在这个用例被困在一个非常特定于这个用例的 BO 中，作为用户删除只是整个用例的一部分。
在某个时间点，您的开发人员被要求合并一个碰巧涉及的不同用例，即删除用户！开发人员可能会做一些事情。 1) 他可能会创建一个新用例，现在涉及删除用户但忘记删除与该用户相关的任何记录。 2) 他可能已经注意到之前的用例，但如果不将其过度概括为他的用例就无法直接使用它，因此他决定将正确删除用户及其相关记录的部分用例复制到他的用例中.现在我们有重复的部分代码实际上做同样的事情 - 删除一个用户。呸！现在，将这个“删除用户”放在 DAL.Users 帮助类中，您就可以避免这种糟糕的设计实践。
无论如何，EF 的一个好处是，它减少了我用来手动创建的业务实体的数量，并从应用程序级别提供了与数据存储级别不同的数据视图。
【讨论】：