我们有一个静态类库来处理重复的多上下文任务。将 EF 数据库上下文创建为静态类的成员是不好的做法吗？
数据库上下文是出于某种原因而被丢弃的。经常处理它们可以使连接池保持“流动”，并且可能（在这里我推测）确保表不会保持锁定状态。
那么我是在为静态类中的数据库上下文带来麻烦，还是我想太多了？
问问题
7776 次
2 回答
14
IMO 这绝对不是你想做的事情。
锁定实际上并不是您将在这里遇到的主要问题。EF 只会在保存更改调用期间锁定（它实际上是使用跟踪图而不是大多数其他 ORM 使用的部分提交事务的一大好处）。
会让你感到厌烦的是跟踪图本身。EF 的工作原理（在大多数情况下）是它保留了它所见过的每个实体的副本，并遍历它们以查找更改的内容并运行一个名为 fixups 的过程，该过程使导航属性与反向链接一起使用。此过程循环遍历上下文所见过的每个实体，并在一系列操作（添加、附加、删除、保存、查询和其他一些操作）上调用。这意味着如果跟踪图很大，则此过程可能需要相当长的时间。如果你让你的上下文永远活着，那么跟踪图的大小就会趋向于你的数据库的大小，这使它变得笨拙和缓慢。
于 2013-01-25T16:49:58.553 回答
6
这取决于很多事情，但这里有一些想法，例如：
- 如果您在服务层上使用 EF - 那么并发性可能是一个问题，因为我认为使用 EF 上下文不是线程安全的，即您可以同时从所有线程使用它而不会出现问题
- 如果你的实体被上下文跟踪（我认为即使你不这样做），上下文会及时变得非常大，最终它可能包含你所有的数据库实体，然后你会遇到性能问题
不管怎样，我认为这是个坏主意。
于 2013-01-25T16:51:20.280 回答