管理 DbContext EF6答案

【问题标题】：Managing DbContext EF6管理 DbContext EF6
【发布时间】：2014-08-06 16:53:49
【问题描述】：

我正在构建 Webforms EF6 数据库第一个应用程序，但不确定如何最好地管理 DbContext。我看了很多教程和论坛帖子，但我仍然确定。关于备受青睐的“按请求使用”，我还没有找到一种一次性拯救父母和孩子的方法。我让它与下面的代码一起工作，但我将在何处以及何时处理上下文？我可以使用这种方法吗？ Kamyar shown here 的按请求方法会更好吗？

这是我现在得到的：

public static class ContextManager
{
    [ThreadStatic]
    private static MyContext current;

    public static MyContext MyCurrentContext
    {
        get{
        if (current == null)
            current = new MyContext();

        return current;
    }}
}

加上

var context = ContextManager.MyCurrentContext;
.....
context.SaveChanges();

提前感谢您的帮助！

一个具体的例子是“UserProfile”，它包含子对象作为属性，例如“DefaultInvoiceAddress”，它从包含所有用户地址的表中返回用户的默认发票地址。在我处理的最后一个 Web 应用程序中，当用户从配置文件中编辑此地址（例如街道变化）以及来自其他表的其他配置文件信息时，EF 会将来自不同表的所有编辑信息保存在一个请求中（确保他们重新附上）。由于我不知道上下文管理，我不知道它是如何完成的，但我们总是会为请求分配一个通用的当前上下文。

我遇到了this post by Rick Strahl 和this one by Jordan van Gogh - 业务对象/事务似乎是一个答案，但我不太了解如何实现它并且找不到示例。 “每个 HTTP 请求的共享 ObjectContext 实例”对应于上面提到的 Kamyar 的答案，考虑到所有因素，这听起来是一个不错的选择。我是否必须明确处理上下文，如果是这样，何时/何地？有什么缺点吗？

【问题讨论】：

您能解释一下“一次性拯救父母和孩子”是什么意思吗？最好有代码示例。

标签： c# entity-framework dbcontext

【解决方案1】：

坏主意。静态完全违背最佳实践。没有 2 个用户会同时使用该应用程序？哎哟。对于 Web 表单。

按要求是最好的选择。

【讨论】：

谢谢，我很欣赏您所说的，但是如何从更改跟踪中受益并在一个块中实现父/子保存？当我尝试附加孩子时，它会给出“不是来自同一上下文”的错误
@devlock 也许您可以编辑您的问题并给我们一个更具体的使用场景示例。

【解决方案2】：

EF db 上下文对象是 not，我重复 NOT 线程安全，无论您如何管理它。跨线程共享数据库上下文可能会出现很多问题，因此最好的方法是，如上所述，按请求使用它。

如果您不想跳入 IoC/DI 方面，一个非常简单的方法是，只要您需要数据库，您只需在 using 块中实例化您的上下文，如下所示：

using(var db = new MyContext())
{
    // code reading from/writing to database
    ...
    ...
}

【讨论】：

感谢您的意见，我在上面添加了一条评论，也适用于您的回答

【解决方案3】：

在实体框架数据库上下文中使用单例模式是一个设计缺陷，特别是如果您使用 Web 表单等并发环境，因为您必须考虑到 DbContext 不是线程安全对象。

【讨论】：