0

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

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

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

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

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

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

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

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

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

提前致谢。

4

2 回答 2

2

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

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

但我不会以这种方式使用扩展方法。我宁愿有一个数据层，它具有（服务）方法，可让您指定所需内容并返回IEnumerables（注意：不是IQueryables）并完全封装上下文。但这可能是您当前设计的重大偏离。至少我只会通过 Linq 语句从数据层扩展 IQueryables。如果您需要加入或包含，请让数据层根据您在我们的方法中询问的数据应用它们。

只是一个建议：D

于 2012-06-11T11:47:52.283 回答
0

如果您必须在生命周期之间架起桥梁，您可以围绕您的上下文创建一个包装器，以处理您的上下文的创建和拆卸。看看Mark Seemann 的帖子。

于 2012-06-11T08:06:39.567 回答