3

我正在努力解决以下问题。

我有一个带有表Jobs的数据库，其中包含有关要完成的作业的信息。我遵循 EF 6.0 的 Code First 方法并创建了一个名为Job的 POCO 类。然后我在数据库中查询作业：

DbSet<Job> receivedJobs;
using (var context = new MyContext())
{
    receivedJobs = (from j in context.Jobs
            select j);
}

使用接收到的集合receivedJobs然后我将进行耗时的优化。

据我了解，上下文的生命周期以及上下文控制的资源以 using 语句的右括号结束。此外，一个好的设计应该在不再需要数据库时立即将资源释放到数据库中。

我的问题是现在我应该怎么做？只需保持数据库上下文处于活动状态，直到我完成耗时的优化任务。或者关闭连接，因为在优化结束之前不需要它。但在后一种情况下，我该如何处理已处理的Job对象，因为我将需要访问它们的一些导航属性，因为上下文已关闭，所以我无法访问。（顺便说一句，Job类的实例中的数据不会因为优化而改变。所以不需要跟踪这些对象的变化，因为不会有任何变化）

希望有人可以帮助我了解在这种情况下推荐的设计是什么。

此致

4

2 回答 2

1

尽管它不能解决您所有的问题，特别是设计问题，但您知道预加载工作导航属性的“包含”功能吗？例如，如果一个作业由于名为“Tasks”的属性而指向一个任务列表：

context.Jobs.Include("Tasks") //将预加载您的作业的 Tasks 属性。

context.Jobs.Include("Tasks.AllowedUsers") //将预加载您的作业的 Tasks 属性，以及每个任务的 AllowedUsers 列表。

如果您想在同一级别预加载多个属性，只需使用以下内容：

context.Jobs.Include("Tasks").Include("OtherTasksOnJob")

于 2013-08-05T14:49:49.233 回答
1

您应该始终在执行操作所需的最少时间内保持上下文。在您的情况下，听起来您在优化完成之前需要上下文，因为您正在使用它的一些方法来导航结果集。如果是这种情况，则应保留上下文，直到您不需要它为止。

要避免的坏习惯是在你没有立即需要的情况下坚持上下文。您将看到一些应用程序在应用程序启动时错误地创建了一个上下文，并在应用程序的生命周期内保持它。这很糟糕，而且浪费资源。

在您的情况下，将优化代码放在适当的位置，使用上下文直到代码完成，然后释放上下文。您的 using 语句将处理所有杂乱的处置内容。只需在 {} 中获取需要上下文以供使用的代码，您就可以开始使用了。

于 2013-08-05T14:49:51.900 回答