控制台应用程序的Db上下文

Question

我有一个用C＃编写的控制台应用程序，它每小时作为服务运行。该应用程序具有数据访问层（DAL）以使用Db上下文连接到数据库。此上下文是DAL的属性，每次创建DAL时都会创建。我相信这在更新各种元素时会导致错误。

问题：应用程序在运行时是否应创建Db Context并在整个应用程序中使用它，以便所有对象都使用相同的上下文进行处理？

Answer 1

由于服务可以运行很长时间，因此最好打开连接，完成工作然后关闭连接。

如果您有方法的节奏，那么您可以将打开的DbContext作为参数传递。

例如：

   call to A

      call to B(DbConteext)

          call to C(DbContext)

另一个好的做法是使用try / catch保护您的代码，因为您的数据库可能处于脱机状态，无法访问等等。

Answer 2

DbContext实际上是工作单元模式的实现，因此它表示单个业务事务，通常是Web应用程序中的请求。所以它应该在业务事务开始时实例化，然后应该执行和提交对db的一些操作（即SaveChanges），并且应该关闭上下文。

如果运行控制台应用程序代表业务事务，那么它有点像Web请求，那么当然您可以拥有DbContext的单例实例。你不能在不同的线程中使用这个实例，所以你的应用程序应该是单线程的，你应该知道DbContext正在缓存一些数据，所以最终你可能会遇到内存问题。如果您的数据库被许多客户端使用并且数据经常发生更改，那么如果从数据库中获取某些数据并保存它们之间的时间太长可能会出现问题，则可能会出现并发问题。

如果没有尝试将您的应用分成某些业务事务，并根据这些事务解析您的数据库上下文。这样的交易可以是用户输入的命令。

Answer 3

  

问题：应用程序在运行时是否应创建Db Context并在整个应用程序中使用它，以便所有对象都使用相同的上下文进行处理？

每当您怀疑基础数据发生变化时，您应该（重新）创建DbContext。因为DbContext假设从数据源获取的数据永远不会更改，并且可以作为查询的结果返回，即使该查询可能会在几分钟，几小时或几年后发生。它是缓存，具有所有优点和缺点。

每当您开始新的服务循环时，我建议您（重新）创建DbContext。