18

问题

在 MVC Web 应用程序中跨多个存储库共享 EF DbContext 的正确方法是什么？这样做是否谨慎/有必要，这样做或不这样做有什么陷阱？

背景

认为：

  • App.MvcSite（几十个控制器，多个区域等）
  • App.Services（服务层，很多服务）
  • App.Data（许多存储库等）
  • ...等为简单起见排除（EF Code First 最新）

迄今为止的研究

我似乎在 SO 和互联网上找到了至少两/三种思想流派。

  1. 将您的 DbContext 共享/范围到请求，以便单个请求具有由所有存储库共享的单个 DbContext。
  2. 在服务层共享/限定您的 DbContext —— 服务维护单个 DbContext 并根据需要将其传递给每个存储库。
  3. 不要共享 DbContext，因为它们很便宜，让每个 Repo 都有自己的。

在一个小型网站中，这不是问题，这就是为什么大多数 MS 和社区示例根本没有解决这个问题。

到目前为止，根据我的经验，我还没有使用过有限的存储库。我一直让服务使用 DbContext 并直接更改它，所以我不需要担心这一点。有人告诉我，从单元测试的角度来看，有限存储库有很大的好处……我们会看看它是否让剩下的事情变得有价值。

我的想法

(1)将您的 DbContext 共享/范围到请求

这很有趣，因为它巧妙地避免了单例上下文的陷阱，一些开发人员认为这是答案，但发现 DbContext 不能那样工作。但它似乎有一个缺点，因为它假定所有存储库、服务等都将在整个请求中进行协调......这通常不是这种情况，对吗？如果一个 repo 在另一个 repo 完成其工作之前保存了更改会怎样。（外（内（内）））

(2)在服务层共享/限定您的 DbContext

这对我来说更有意义，因为每个服务都应该协调一个特定的工作单元（故意小写）。因此，如果在一个请求中使用了多个服务，那么每个服务都有自己的数据库上下文是正确的（如果不需要的话）。

(3)不要共享 DbContext，因为它们很便宜

这就是我一直这样做的方式......实际上我几乎总是每个请求只有一个 DbContext，因为只有一个服务被调用。有时可能是两个，因为协调工作的控制器调用了两个服务。但是考虑到我当前的应用程序，有许多有限的存储库，每个存储库都有自己的上下文意味着一个给定的请求可能有 3-10 个 DbContext 实例。我假设（也许是错误的）这是有问题的。

重复问题：

在 MVC Web 应用程序中跨多个存储库共享 EF DbContext 的正确方法是什么？这样做是否谨慎/有必要，这样做或不这样做有什么陷阱？

4

2 回答 2

5
  • DbContext很便宜，但分布式事务却不是。
  • 附加到一个上下文的对象不能在另一个上下文中使用（如果您有对象关系）

共享上下文的最简单方法是开始使用控制容器的反转：http: //www.codeproject.com/Articles/386164/Get-injected-into-the-world-of-inverted-dependenci

于 2013-02-27T13:48:05.523 回答
1

我会选择前两个选项之间的组合，关于你对第一个选项的看法，不要让存储库保存任何更改（这不是推荐的做事方式，Martin Fowler 说他自己），为此他介绍了工作单元模式。

于 2013-02-27T23:35:11.203 回答