EF6 NotMapped 属性在请求范围之外反序列化答案

【问题标题】：EF6 NotMapped Property deserialized outside of request scopeEF6 NotMapped 属性在请求范围之外反序列化
【发布时间】：2015-05-28 15:51:27
【问题描述】：

我的 webapi 应用程序设置为处理多个数据库连接，方法是使用 MessageHandler 根据请求标头设置数据库连接。然后我在创建上下文时使用这个连接实例。这部分效果很好。

但是，我在大多数实体上都有一个 [NotMapped] 属性，它需要一个上下文，以便我可以对数据库运行额外的查询（显然，实体来自同一个数据库）。

问题是，webapi 似乎在意识到它具有未映射的属性之前完成了请求，然后潜入管道以检索该属性。但是，此时，我退出了我的消息处理程序，我的连接实例不再设置，当我尝试在属性 getter 中创建上下文时，我从连接实例中得到一个 NullRefException。

这就是我在脑海中的看法：

我的第一个想法是，必须有一种方法可以从实体中获取上下文。但是，在 EF6 中，all Entities are simply POCOs which have no knowledge of their context.（见第一条评论）

我唯一能想到的就是在每个实体中手动设置一个上下文实例，这样我就可以在NotMapped 属性中引用它，但这似乎是最粗略的。

我看错了吗？
有什么解决方案的建议吗？（或者可能澄清NotMapped 属性的实际处理方式？）

编辑：进一步检查，似乎错误是由 JSON 序列化过程引发的。 (Newtonsoft.Json.JsonSerializationException) 所以看起来返回的 IQueryable 在序列化过程中被评估，然后它尝试评估 [NotMapped] 属性，并且由于连接实例不再存在而失败。

我必须假设我想要完成的事情是可能的，我只是不确定现在如何。 基本上我需要 `[NotMapped]' 属性来了解创建实体的上下文。 非常感谢您的建议！

【问题讨论】：

让我看看我是否明白。您正在尝试在 POCO 中实现手动延迟加载？您是否意识到您错过了 UoW 的重点？
@JoãoSimões 我没有手动实现延迟加载，我正在使用带有WebAPI 的Breeze，它默认返回一个IQueryable。我正在尝试使用 IQueryables（延迟加载）保持，以便 OData 继续工作。但是，我需要为每个实体加载一些额外的数据，但是在评估 IQueryable 时我的上下文丢失了。我当前的解决方案（见答案）是自动保存一些我需要重新创建相同上下文的信息（在多连接环境中），以便在评估 IQueryable 时，它知道在哪里加载附加数据来自。

标签： c# entity-framework asp.net-web-api entity-framework-6

【解决方案1】：

我不认为这是最好的解决方案，但由于还没有人提出任何其他建议，所以我发布了我迄今为止提出的建议：

我最终做的是向我的所有实体派生的BaseEntity 类添加一个connectionString 变量。在BaseEntity 构造函数中，我将此属性设置为创建实体时正在使用的当前连接字符串（此时在范围内）。

然后，每当稍后访问我的 [NotMapped] 属性（用于反序列化或其他）时，我都会引用实体上的连接属性来创建我的上下文。

类似这样的：

public class BaseEntity
{
    public BaseEntity()
    {
        // Save current connection string being used to create the entity. 
        // ConnectionManager.Instance.CurrentConnection will be null by the time deserialization happens
        _connectionString = ConnectionManager.Instance.CurrentConnection.ConnectionString;
    }

    private readonly string _connectionString;

    [NotMapped]
    public string MyProperty
    {
         using (var ctx = new MyContext(_connectionString))
             ...
    }
}

到目前为止，这似乎工作得很好，我认为这将是我的解决方案。请随时提出任何替代/改进的解决方案。

【讨论】：