如果您计划序列化您的POCO，您是否需要放弃EntityFramework中的代理对象？

我很困惑。整个代理对象似乎是通过使用延迟加载和更好的更改跟踪来提高性能。但是，当您从Linq检索代理结果到EF查询并且希望通过HTTP将结果作为JSON返回时，由于存在类型不匹配，您将因序列化而发生错误。如果您计划序列化您的POCO，您是否需要放弃EntityFramework中的代理对象？

所有解决方案都表示关闭代理服务器。那么如果你不能使用它们，那么它们有什么意义呢？我错过了什么，如何返回序列化的代理对象，而不实例化新的非代理匿名类型或POCO类型（对象分配）来镜像我要返回的每个对象？

来源

2013-03-25 brushleaf

代理对象的序列化将递归地触发所有导航属性的延迟加载。这是你想要达到的目标吗？在高度连接的模型中，它可能会导致“完整的数据库”。 – 2013-03-25 09:51:05

使用延迟加载/代理的性能改进是，您不会一次抓取所有数据，从而更快地往返数据库，减少减慢甚至阻止其他数据库操作的可能性。如果你知道你会加载所有的数据，它不一定是一个性能的改善。

也就是说，如果您不能使用Include（...）（由于其局限性，例如GroupBy），有一些选项。

要加载具有多次到DB的数据的数据，您可以使用引用或集合属性上的Load方法显式加载数据而不访问它。您可以然后禁用代理生成。（http://blogs.msdn.com/b/adonet/archive/2011/01/31/using-dbcontext-in-ef-feature-ctp5-part-6-loading-related-entities.aspx）

如：

context.Entry(entityObj).Reference("PropertyName").Load(); 
context.Entry(entityObj).Collection("PropertyName").Load();

如果你想利用延迟加载W /代理的某些属性，但要避免试图延迟加载他人一旦环境被设置WCF数据契约序列化，您可以在离开数据库上下文的范围之前分离实体。

EntityA a = null; 
EntityA a2 = null; 

using (var db = new TestEntities()) 
{ 
    a = db.EntityAs.Where(ea => ea.Id == 1).Single(); 
    db.Entry(a).State = System.Data.EntityState.Detached; 

    a2 = db.EntityAs.Where(ea => ea.Id == 2).Single(); 
} 

var b1 = a.EntityB; // c will remain null; no exception thown 
var b2 = a2.EntityB; // blows up b/c it attempts to lazy load

来源

2013-03-26 22:21:08 Moho

如果您计划序列化您的POCO，您是否需要放弃EntityFramework中的代理对象？

回答

相关问题