我们直接使用Azure缓存（而不是通过其中一个可用的Entity Framework包装器）。显然，对于分布式缓存，我们需要序列化对象。不幸的是，这会导致用于导航属性的基于延迟加载DbContext的代理问题。
我看到我们可以使用custom serializer来将代理映射到空集合（如果没有加载）或映射到普通对象（如果已加载），但我不确定实现。一种可能的实现可以基于the one used by WCF，但我不确定Azure的工作方式是否相同。
理想的解决方案（这就是我指向ProxyDataContractResolver的原因）将是序列化发生时的原因：
有没有人以优雅的方式手动修复该问题？
提前致谢！
答案 0 :(得分：2)
我将假设如果您想要缓存EF对象，则不需要对这些实体进行延迟加载或更改跟踪。
我相信这两个都是通过会导致序列化问题的对象代理启用的（因为你不想序列化代理）。
如果禁用属性 DbContext.Configuration.ProxyCreationEnabled ，则实际对象（而非代理）的序列化应该可以正常工作。在通过WCF返回POCO对象时通常需要这样做，但对于其他序列化方案（例如此情况）则可能相同。
答案 1 :(得分：1)
如果在序列化之前从DbContext中分离EF实体，则会禁用延迟加载，因此您的自定义序列化程序不会尝试序列化任何不属于实体图形的内容。
然后当你从缓存中获取它时，如果你将它附加到一个新的（相同的）DbContext，那应该重新启用延迟加载。
（警告：一旦你将实体从上下文中分离出来，任何包含同一个对象的新查询都会创建一个新的附加副本，所以你需要小心编写代码以避免遇到多个潜在的问题 - 运行的同一个对象的不同版本。但是，这应该让你做你想做的事。）