在MVC Web应用程序中,跨多个存储库共享EFDbContext的正确方法是什么?这样做是否审慎/有必要,这样做或不这样做的缺点是什么?
假设:
在一个小的网站上,这是一个非问题,这就是为什么大多数MS和社区的例子根本没有解决这个问题。
根据我的经验,到目前为止,我还没有使用有限存储库。我一直让服务使用一个DbContext并直接修改它,所以我不需要担心这个问题。从单元测试的角度来看,我被告知有限存储库有很大的好处…我们将拭目以待其馀部分是否值得。
(1)对请求的DbContext共享/作用域
这很有趣,因为它巧妙地避免了一些开发人员认为是答案的单例上下文的陷阱,但发现DbContext不是这样工作的。但它似乎有一个缺点,因为它假设所有存储库、服务等都将在整个请求中协调一致…这通常不是这样的,对吗?如果一个回购在另一个回购完成其工作之前保存了更改,怎么办(外部(内部)
(2)在服务层共享/范围您的DbContext
这对我来说更有意义,因为每个服务都应该协调一个特定的工作单元(更低的情况是有意的)。因此,如果在一个请求中使用了多个服务,那么每个服务都有自己的数据库上下文。
(3)不要共享DbContext,因为它们很便宜
发布于 2018-05-17 08:15:42
DbContext
很便宜,但分布式事务不是。发布于 2018-05-17 09:28:47
我会在前两个选项之间进行组合,对于第一个选项,不要让存储库保存任何更改(MartinFowler说,这不是建议的做法),为此,他引入了“单元工作模式”(Unit Of Work Pattern)。
https://stackoverflow.com/questions/-100004513
复制相似问题