我们一直在使用以下堆栈开发一个新应用程序：
SQL Server 2008 R2 -> 实体框架 4.2 -> WCF 数据服务 -> WCF 数据服务客户端库
这都是 .NET 4.0
现在，WCF 数据服务客户端库对于少量数据和简单的模式/对象图非常方便，但对于更复杂的模型来说它是一条真正的狗。特别是，我们发现 DataServiceContext.Links 集合的规模类似于 O(n^2)：加载的相关对象越多，图的嵌套越多，它变得越慢，直到加载数据需要更长的时间进入上下文而不是从电线上读取它。
例如，我们有一个包含 2000 个成员的集合，每个成员都有 4 个导航属性。在不扩展任何导航属性的情况下拉出整个集合大约需要 1 秒。展开所有 4 个导航属性需要 5 秒。我们已经测量了堆栈中各个点的性能，大部分额外时间都花在了客户端上，用于整理数据。
对于大型数据集，我们采用了各种技术来解决这个问题：
- 非规范化。这对于我们总是展开的那些图很有效。如果我们想延迟加载图表的一部分，效果就不太好了。
- 分别加载相关对象，并在数据上下文之外将它们拼接在一起。这很烦人，但它确实克服了 context.Links 问题。
- 使用多个数据上下文将 Links 集合的压力降至最低。
- 使用 MergeOption.NoTracking 连接 w/ (1) & (2)
有人知道其他技术吗？加载相关对象时是否存在可能导致不必要开销的设置？
有时，我们似乎已经完成了编写自己的自定义上下文的一半，我想要在它变得更详细之前进行一次完整性检查。
[是的，我意识到 WCF 数据服务可能不适合这项工作。唉，我们已经走上了这条路]