Question

我的扩展方法中的上下文和可用性存在问题。

基本上我正在使用UNITY，目前它每次调用我的数据层时都会为我提供一个新的DBContext实例（它被注入到构造函数中）。

我还放置了一些与IQueryable一起使用的扩展方法，数据层返回，所以我可以实际执行以下操作。

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

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

问题是我的dbContext已经注册，每次给我一个新实例，所以我得到“不同上下文......”的错误。

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

我使用EF 4.1和POCO类，没有跟踪，我有一个模型。因此，对其他表进行连接的唯一方法是访问我的dbcontext？

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

提前致谢。

Answer 1

坦率地说，拥有依赖于或影响数据上下文生命周期的扩展方法有点臭。扩展方法应该执行相对简单的任务，而不依赖于外部状态并且不会产生副作用。它们适合函数式编程范例。 Queryable的扩展方法就是一个很好的例子。除了提供的参数之外，它们不需要任何其他内容，永远不会更改全局状态甚至参数对象并返回新的值或对象。

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

但我不会这样使用扩展方法。我宁愿有一个数据层，它有（服务）方法，让你指定你需要的东西，并返回IEnumerable s（注意：不是IQueryable s）并完全封装上下文。但这可能是您当前设计的主要偏差。至少我只会通过Linq语句从数据层中释放IQueryables。如果您需要连接或包含，请让数据层根据您在我们的方法中提出的数据应用它们。

只是一个建议：D

Answer 2

如果必须在生命周期之间架起桥梁，您可以在上下文中创建一个包装器来处理上下文的创建和拆除。看看Mark Seemann's post。

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

2 个答案: