自跟踪实体流量优化

Question

我正在使用WPF与实体框架和自我跟踪实体进行一个个人项目。我有一个WCF web服务，它公开了CRUD操作的一些方法。今天，我决定做一些测试，看看这个服务上到底有什么内容，尽管我预料到了这样的事情，但我还是感到非常失望。问题是，对于一个对象的简单更新(或删除)操作--假设类别，我向服务器发送整个对象图，包括它的所有父类别、它们的项、子类别和项等。我的例子是，它是一个非常小的数据库上的一个170 KB的xml文件(两个主要类别，大约20个总目录和大约60个项)。我无法想象如果我有一个很大的数据库会发生什么。

我试着用谷歌搜索一些关于STE流量优化的文章，但是没有成功，所以我决定在这里询问是否有人做过类似的事情，是否知道一些好的实践等等。

我提出的一种可能的方法是通过更多的服务调用获取每个对象所需的数据：

return context.Categories.ToList();//only the categories
...
return context.Items.ToList();//only the items

而不是：

return context.Categories.Include("Items").ToList();

这样，类别和项将被分开，在更改或删除某些对象时，通过连线发送的数据将减少。

你们中有谁面临过类似的问题，你们是如何解决的，还是解决的？

Answer 1

我们也遇到过类似的挑战。首先，正如您已经提到的，是保持实体尽可能小(按照所需客户端功能的要求)。其次，当将实体发送回要持久化的线路上时:删除所有未更改的导航属性(嵌套对象)。这听起来很简单，但一点也不简单。我们要做的是递归地挖掘可跟踪集合中存在的实体，比如“最顶层”实体(以及它们的可跟踪集合，以及.)并在它们的ChangeTracking状态“不变”时移除它们。但是要小心这一点，因为在某些情况下，您仍然需要这些实体，因为它们已经被移除或添加到其父实体的可跟踪集合中(因此不应该删除它们)。

我们称之为"StripEntity“的内容在朱莉·勒曼-程序设计实体框架中也提到了(没有任何代码示例或任何代码示例)。

虽然它可能不像一种更纯粹的方法那样高效，但使用STE的方法可以节省大量针对数据库的查询代码。在高流量的情况下，我们不需要最优的性能，所以STE适合我们的需要，需要大量代码与数据库进行通信。你必须根据你的情况决定什么是“最好的”解决方案。祝好运!

Answer 2

您可以在http://selftrackingentity.codeplex.com/中找到实体框架项目项。在0.9.8版本中，我添加了一个名为GetObjectGraphChanges()的方法，它返回一个优化的实体对象图，其中只包含有更改的对象。

另外，还有两个助手方法：EstimateObjectGraphSize()和EstimateObjectGraphChangeSize()。第一种方法返回整个实体对象的估计大小及其对象图；后一种方法返回优化的实体对象图的估计大小，只包含有变化的对象。使用这两个助手方法，您可以决定调用GetObjectGraphChanges()是否有意义。