标签: wcf-data-services-client

我们一直在使用以下堆栈开发一个新的应用程序:

SQL Server 2008 R2 - >实体框架4.2 - > WCF数据服务 - > WCF数据服务客户端库

这都是.NET 4.0

现在,WCF数据服务客户端库非常便于小数据和简单的模式/对象图,但它对于更复杂的模型来说是一个真正的好处.特别是,我们发现DataServiceContext.Links集合可以扩展O(n ^ 2):你加载的对象越多,你的图表嵌套越多,它就越慢,直到加载数据需要更长的时间进入上下文比它从线上读取它.

例如,我们有一个拥有2000个成员的集合,每个成员有4个导航属性.在不扩展任何导航属性的情况下拉动整个集合大约需要1秒钟.扩展所有4个导航属性需要5秒.我们测量了堆栈中各个点的性能,并且大部分额外时间花在客户端上,整理数据.

我们采用了各种技术来解决大数据集:

1. 非规范化.这适用于我们始终扩展的图形.如果我们想延迟加载图形的一部分,那么效果不好.
2. 分别加载相关对象,并在数据上下文之外将它们拼接在一起.这只是烦人的,但它确实克服了context.Links问题.
3. 使用多个数据上下文将Links集合的压力降至最低.
4. 连接中使用MergeOption.NoTracking w /(1)&(2)

有谁知道其他任何技术？在加载相关对象时,是否存在可能导致不必要开销的设置？

有时看起来我们正在编写自己的自定义上下文的一半,我想在它变得更精细之前进行健全性检查.

[是的,我意识到WCF数据服务可能是错误的工具.唉,我们已经走了这条路]

问题

在Web API上的OData 4服务中,从.NET客户端调用嵌套$ expand的正确方法是什么？我们正在使用OData客户端生成器.回到之前使用OData 3服务的WCF数据服务,我们可以调用.Expand("Customers/Orders").在使用OData 4的Web API中,我们不能再这样做,并且如果您尝试,则会收到以下内容.Expand("Customers/Orders"):

URI中指定的查询无效.找到遍历多个导航>属性的路径.请重新调整查询,使每个展开路径仅包含类型>段和导航属性.

解决方法

我们可以通过调用expand来解决这个问题:.Expand("Customers($expand=Orders)").在非嵌套的$ expand场景中,我喜欢lambda支持.Expand(d => d.Customers)..NET OData 4客户端是否有正确的方法来调用嵌套的扩展而没有不幸的魔术字符串.Expand("Customers($expand=Orders)")？如果没有,是否有一个更清洁的字符串模式,如"客户/订单",这将有效吗？谢谢.