EF/LINQ：在扩展方法中获取上下文，上下文应该是短期的

我对扩展方法中的上下文和可用性有问题

基本上我使用的是UNITY，现在每当我调用我的数据层（它被注入构造函数）时，它都会为我提供一个新的DBContext实例

我还放置了一些扩展方法，用于数据层返回的IQueryable，因此实际上我可以执行以下操作

var result = dataLayer.GetItems().WithId(3)

withID是一个扩展方法，我还有其他扩展方法，我需要在表上进行连接，因为表/字段不在我的IQueryable中

问题是每次注册dbContext时都会给我一个新实例，所以我会得到一个“不同上下文…”形式的错误

但我应该将Unity配置为每次都提供相同的dbcontext实例，因为dbcontext应该是短期的。当然，如果我这样做了，我想我的问题会得到解决，因为数据层和扩展方法将使用相同的DBContext对象

我使用EF4.1和POCO类，没有跟踪，我有一个模型。因此，在附加表上进行连接的唯一方法是访问my dbcontext

有人对我的选择有什么建议吗

---

提前感谢。

如果您必须在生命周期之间搭建桥梁，您可以围绕您的上下文创建一个包装器，用于处理上下文的创建和拆卸。

---

看看。

坦率地说，使用依赖于或影响数据上下文生命周期的扩展方法有点难闻。扩展方法应该在不依赖外部状态和不产生副作用的情况下完成相对简单的任务。它们适合于函数式编程范式。扩展方法就是一个很好的例子。它们不需要任何东西，只需要提供的参数，永远不会更改全局状态甚至参数对象，并返回新的值或对象

如果希望以这种方式使用扩展方法，则应通过参数传递数据上下文

但我不会以这种方式使用扩展方法。我更希望有一个数据层，它具有（服务）方法，可以让您指定所需内容，并返回

IEnumerable

s（注意：not

IQueryable

s）并完全封装上下文。但这可能是您当前设计的一个重大偏离。至少我只会通过Linq语句从数据层中exend IQueryables。如果您需要联接或包含，请让数据层根据您在我们的方法中要求的数据应用它们

---

只是一个建议：太好了，谢谢你的建议。因此，我应该在数据层中使用连接返回所有字段，然后在服务层中，我只需要调用扩展方法，不需要在上下文中传递，因为我需要执行WHERE on的字段已经包含在字段中。。因此没有加入？这就是你指的？如果我没弄错的话。。。听起来不错。返回IEnumerable vs IQueryable有什么好处呢？至于IQueryable vs IEnumerable:IQueryable是一个“泄漏”接口：它公开了实现细节（重要的是哪个linq to xxx支持它）。此外，它允许服务外部的代码对发送到数据库的查询产生深刻影响。这可能会影响性能和可测试性。这是您希望数据层控制的。试试谷歌，你会看到很多关于这个话题的讨论。至于你的第一条评论：是的，这项服务将塑造你所需要的数据。“我不确定你是否还需要使用自制的扩展方法。”马丁看了看马克·希曼的作品。他讨论了为什么在使用

IQueryable