4

我们直接使用 Azure 缓存（而不是通过可用的实体框架包装器之一）。显然，对于分布式缓存，我们需要序列化对象。不幸的是，这会导致用于导航属性的基于 DbContext 的延迟加载代理出现问题。

我看到我们可以使用自定义序列化程序将代理映射到空集合（如果未加载）或普通对象（如果已加载），但我不确定实现。一种可能的实现可以基于WCF 使用的实现，但我不确定 Azure 的工作方式是否相同。

理想的解决方案（这就是我指向 ProxyDataContractResolver 的原因）是在序列化发生时：

  • 如果导航属性已经加载，数据将被序列化，就好像它是一个普通的集合一样，
  • 如果它们没有被加载，它们将不会被序列化（对于后一种情况，我希望延迟加载在反序列化后恢复工作，但如果不加载也是可以接受的）。

有没有人以优雅的方式手动解决了这个问题？

提前致谢！

4

2 回答 2

2

我假设如果您想要缓存 EF 对象，则不需要延迟加载或对这些实体进行更改跟踪。

我相信这两者都是通过对象代理启用的，这会导致序列化问题（因为您不想序列化代理）。

如果禁用属性DbContext.Configuration.ProxyCreationEnabled则实际对象的序列化，而不是代理，应该可以正常工作。这通常在通过 WCF 返回 POCO 对象时是必需的，但对于其他序列化场景（例如这种情况）可能相同。

于 2013-01-12T00:26:18.637 回答
1

如果在序列化之前将 EF 实体从 DbContext 中分离出来，则会禁用延迟加载，因此您的自定义序列化程序不会尝试序列化任何不属于实体图的任何内容。

然后，当您从缓存中取回它时，如果您将它附加到一个新的（相同的）DbContext，那应该会重新启用延迟加载。

（警告：一旦你将实体从上下文中分离出来，任何包含相同对象的新查询都将创建一个新的、附加的、副本，因此你需要小心编码以避免遇到多个可能不同版本的问题同一个对象跑来跑去。但这就是说，这应该让你做你想做的事。）

于 2013-01-14T14:06:36.207 回答