实体框架 - 解决延迟加载的性能问题的最佳实践

Question

我已经接管了实体框架的项目。代码看起来很好，并且结构良好。问题是我已经多次看到Entity Framework，他们他们使用延迟加载很多。直到db获得一些数据并且sql查询刚刚达到峰值时，问题才会消失。

该解决方案很好地利用了储存库的小而且获得一个级别的数据，当我处理一些最大的性能问题时，最常见的问题常常通过向加载的存储库添加特定函数来解决嵌套的实体并使用一些动态查询。

即GetCustomerWithOrderData，包括订单，订单行等

有时候，我不得不先合并两个查询获得客户（与包括关系），然后拿到订单（与包括），并通过LINQ一起制作地图。

查询比例子复杂得多，延迟加载可能出现在业务层，控制器或视图中，因此无法跟踪解决。

但我觉得代码非常大，我很难找到未来的问题。我现在需要的是一个很好的方式来跟踪何时进行延迟加载，并且还能够告诉在特定的调用中需要加载哪些对象。

最好的是，如果我可以跟踪特定的行动呼吁，并得到了哪些SQL执行，多少次，加载时等

的解决方案是建立与MVC 3和EF4，没有任何性能通过升级到更新的EF获得收益？

Answer 1

在之前的工作中，这成了一个问题，因为开发人员会滥用该框架并在整个地方创建问题 - 仅在表格变大时才显示出来。加上延迟加载会导致json序列化的问题，以及如果你没有指定序列化深度来停止在1 - 即使有时相关的对象会在那里是奇怪的，在其他时候它们不会（依赖于在深度上）。

最后，我们完全关闭了延迟加载，迫使开发人员进行第二次数据库调用以获取他们所需的子实体。另外，团队被指示在开发过程中离开Sql Server Profiler，以确保没有任何事会导致性能被创造。

这种方法也有一定的缺点，比如额外往返数据库，额外的代码行，以及新开发人员对团队普遍缺乏理解，为什么我们要做这样的事情。一些人认为我们可以在我们的查询中使用包含，但是在某些时候，我们的存储库变得越来越臃肿，并且简单性/可读性也很重要。最后，性能问题变得不存在，所以在我看来，杀死懒惰加载的权衡是值得的。

这不是对问题的直接回答，你问，但也许它会给你一些额外的见解。在你的情况下，我会观察Profiler查看最严重的滥用情况，然后一次一个地修正它，直到你的表现再次被接受。你可能会发现你的解决方法是做类似的事情，并完全消除延迟加载。

我很想看到这个问题的其他答案，因为这是一个重要的话题，在我看来。