C# 控制台应用程序的数据库上下文

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

---

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

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

如果有一系列方法，那么可以将打开的DbContext作为参数传递

例如：

   call to A

      call to B(DbConteext)

          call to C(DbContext)

---

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

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

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

如果没有，请尝试将应用程序分离到一些业务事务中，并根据这些事务解析数据库上下文。这样的事务可以是用户输入的命令

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

只要怀疑基础数据已更改，就应该（重新）创建

DbContext

。因为

DbContext

假设从数据源获取的数据永远不会更改，并且可以作为查询的结果返回，即使该查询可能在几分钟、几小时或几年后返回。它是缓存，有它的优点和缺点

我建议您在启动新的服务循环时（重新）创建

DbContext