自我跟踪实体流量优化

时间:2011-06-20 22:11:06

标签: wpf wcf entity-framework self-tracking-entities

我正在使用带有实体框架和自我跟踪实体的WPF开展个人项目。我有一个WCF Web服务,它公开了一些CRUD操作的方法。今天我决定做一些测试,看看这项服务实际上是什么,即使我期待这样的事情,我真的很失望。问题是,对于一个对象的简单更新(或删除)操作 - 让我们说类别我向服务器发送整个对象图,包括其所有父类别,它们的项目,子类别我的情况是我在一个非常小的数据库上的170 KB xml文件(2个主要类别,总共约20个,约60个项目)。我无法想象如果我有一个非常大的数据库将会发生什么。

我试图谷歌搜索一些与STE有关的流量优化的文章,但没有成功,所以我决定在这里询问是否有人做了类似的事情,知道一些好的做法等等。

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

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

而不是:

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

这样,类别和项目将被分开,当进行更改或删除某些对象时,通过网络发送的数据将会更少。

你们有没有遇到类似的问题,你是如何解决它的?或者你是否解决了这个问题?

2 个答案:

答案 0 :(得分:1)

我们遇到过类似的挑战。首先,正如您已经提到的,是保持实体尽可能小(由所需的客户端功能决定)。第二,当通过线路发回实体以进行持久化时:在未更改时删除所有导航属性(嵌套对象)。这听起来非常简单但并非完全无足轻重。我们所做的是递归地挖掘可跟踪集合中存在的实体,例如“最顶层”实体(及其可跟踪集合,以及它们的......),并在其ChangeTracking状态为“Unchanged”时将其删除。但请注意这一点,因为在某些情况下,您仍然需要这些实体,因为它们已被删除或添加到其父实体的可跟踪集合中(因此您不应删除它们)。

Julie Lerman's - Programming Entity Framework中还提到了我们称之为“StripEntity”的内容(不包含任何代码示例或任何内容)。

虽然它可能不如更纯粹的方法那样有效,但使用STE可以为数据库查询节省大量代码。我们不需要在高流量情况下获得最佳性能,因此STE适合我们的需求并且需要大量代码来与数据库进行通信。您必须根据自己的情况决定“最佳”解决方案。祝你好运!

答案 1 :(得分:1)

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

此外,还有两种辅助方法:EstimateObjectGraphSize()EstimateObjectGraphChangeSize()。第一种方法返回整个实体对象的估计大小及其对象图;并且后者仅返回具有更改的对象的优化实体对象图的估计大小。使用这两种辅助方法,您可以决定是否有必要调用GetObjectGraphChanges()