将db上下文放在静态类库中的优缺点

Question

我们有一个静态类库来处理重复的多上下文任务。将EF db上下文创建为静态类的成员是不好的做法吗？

DB上下文是出于某种原因而被处理掉的。经常处理它们会使连接池“流动”，并且可能（这里我推测）确保表不会保持锁定状态。

所以我在静态类中使用db上下文时遇到麻烦，还是我在思考这个问题？

Answer 1

IMO这绝对不是你想要做的事情。

锁定实际上不是你将要遇到的主要问题。 EF只会在保存更改调用的持续时间内锁定（这实际上是使用跟踪图对大多数其他ORM使用的部分提交事务的一大好处。）

导致greif的是跟踪图本身。 EF的工作原理（在大多数情况下）是它保留了它所见过的每个实体的副本并循环遍历它们以找到更改的内容并运行一个名为fixups的过程，这使得导航属性可以与反向链接一起使用。这个过程循环遍历上下文所见过的每个实体，并在一堆操作（添加，附加，删除，保存，查询和其他一些操作）上调用。这意味着如果跟踪图很大，这个过程可能需要相当长的时间。如果你的上下文永远存在，那么跟踪图的大小会趋向于数据库的大小，使其变得笨拙和缓慢。

Answer 2

这取决于很多事情，但这里有一些想法，例如：

• 如果你在服务层上使用EF - 那么并发可能是一个问题，因为我不认为使用EF上下文是线程安全的，即你可以同时从所有线程使用它而没有问题< / LI>
• 如果你的实体被上下文跟踪（我想即使你没有），上下文会变得非常大，最终它可能包含你所有的数据库实体，然后你会遇到性能问题

无论哪种方式，我认为这是一个坏主意。