带有实体框架 4.0 的基本/简单数据访问对象 (DAO)

Question

我正在尝试为在数据层中使用 EF4 的 n 层应用程序构建一个简单的 POC。我查看了网络上的许多示例，使用 DAO 或存储库作为 ORM 的包装器似乎是一种常见的做法。我的理解是，两者之间的主要区别在于 Repository 更通用，并且以 IQueryable 为例作为参数。在这一点上，我希望（无论好坏）坚持使用更简单的 DAO 对象，这些对象将包含相当具体的方法，例如 GetPersonByFirstName(string name)，类似于之前使用基于 ADO.NET 的东西所做的事情。也就是说，我的 DAO 仍然需要几个“跨领域”功能。

1. 如何在 DAO 之间共享上下文？优选地，这将采用实例化 DAO 的业务对象不了解 EF 的方式。最初我认为 BO 会将会话传递给 DAO，但这将违反我对 BO 独立于 EF 的要求（除非我没有想到什么）。也许某种单例/工厂方法？
2. 对于使用请求上下文的 ASP.NET 应用程序，是否有更优雅的方法来处理此问题？基本上是每个请求的会话类型设置，但无需修改任何表示层代码。
3. 我想我可能有一个基类 DAO，它具有非常基本的 CRUD 方法，这些方法将在所有 DAO 之间共享，但又不是 IQueryable。
4. 我想在我的业务对象中使用 TransactionScope 来包装我的 DAO（我认为这不是问题）。

谢谢！

Answer 1

在做了更多研究之后，我似乎在将实体框架上下文存储在 httpContext.Items 中的正确轨道。有很多解决方案基本上可以创建一个以这种方式管理 EF 上下文生命周期的工厂。我对该解决方案的主要问题是我的库不能用于非 Web 项目，所以我认为我需要沿着使用 IoC 容器（而不是工厂）的路径为我注入上下文与生命周期每个请求的对象。这样，如果我需要在控制台应用程序中使用我的库，例如，我可以将配置更改为每线程对象等。