首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >在MVC Web应用程序中跨存储库共享DbContext

在MVC Web应用程序中跨存储库共享DbContext
EN

Stack Overflow用户
提问于 2018-05-17 00:15:36
回答 2查看 0关注 0票数 0

问题

在MVC Web应用程序中,跨多个存储库共享EFDbContext的正确方法是什么?这样做是否审慎/有必要,这样做或不这样做的缺点是什么?

背景

假设:

  • 应用程序MvcSite(几十个控制器、多个区域等)
  • App.Services(服务层,许多服务)
  • App.Data(许多存储库等)
  • .等为简单起见而不包括在内(EF代码第一次)

研究至今

  1. 对请求的DbContext共享/作用域这样,一个请求就有一个由所有存储库共享的DbContext。
  2. 在服务层共享/范围您的DbContext-服务维护单个DbContext,并根据需要将其传递给每个存储库。
  3. 不要共享DbContext,因为它们很便宜让每个回购都有自己的。

在一个小的网站上,这是一个非问题,这就是为什么大多数MS和社区的例子根本没有解决这个问题。

根据我的经验,到目前为止,我还没有使用有限存储库。我一直让服务使用一个DbContext并直接修改它,所以我不需要担心这个问题。从单元测试的角度来看,我被告知有限存储库有很大的好处…我们将拭目以待其馀部分是否值得。

我的思想

(1)对请求的DbContext共享/作用域

这很有趣,因为它巧妙地避免了一些开发人员认为是答案的单例上下文的陷阱,但发现DbContext不是这样工作的。但它似乎有一个缺点,因为它假设所有存储库、服务等都将在整个请求中协调一致…这通常不是这样的,对吗?如果一个回购在另一个回购完成其工作之前保存了更改,怎么办(外部(内部)

(2)在服务层共享/范围您的DbContext

这对我来说更有意义,因为每个服务都应该协调一个特定的工作单元(更低的情况是有意的)。因此,如果在一个请求中使用了多个服务,那么每个服务都有自己的数据库上下文。

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

EN

回答 2

Stack Overflow用户

发布于 2018-05-17 08:15:42

  • DbContext很便宜,但分布式事务不是。
  • 附加到一个上下文的对象不能在另一个上下文中使用(如果有对象关系)
票数 0
EN

Stack Overflow用户

发布于 2018-05-17 09:28:47

我会在前两个选项之间进行组合,对于第一个选项,不要让存储库保存任何更改(MartinFowler说,这不是建议的做法),为此,他引入了“单元工作模式”(Unit Of Work Pattern)。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/-100004513

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档