Asp.net 针对结合查询和业务操作的基于WCF的服务器的建议

背景

我最近用这个杀死了一些神经元。我想为UPS等包裹服务制作一个多层应用程序。长话短说，后端将是基于WCF的服务器，而使用者将是ASP.NET MVC应用程序。其想法是后端将处理所有业务操作，如添加新装运、编辑现有装运、承运人等，但将以表单或查询的形式向消费者提供数据

问题是

我的业务运营计划是，消费者应该像模型一样传递完成操作所需的所有信息，即，对于添加装运，消费者将发送这些装运所需的所有信息。现在，我的实际问题是数据查询

使用者应用程序应该能够以其希望的任何方式显示后端提供的数据，而不受DTO的限制。例如，在列出装运时，我只想显示一个带有名称、ID、装运日期等的网格，而不是整个装运对象图

消费者应用程序如何指定它需要到WCF端点的数据投影

选择权

我考虑创建几个操作方法重载，为不同的目的公开不同的DTO。即：

IList<ShipmentDetailsDTO> GetAllShipmentsAsDetailed(); 

IList<ShipmentListingItemDTO> GetAllShipmentsAsListingItems();

我放弃了这个想法，因为后端正在适应消费者应用程序的需求，这不是一个好的做法。后端应该与消费者无关

另一种选择是将用于查询数据的WCF数据服务与用于业务操作的WCF常规服务相结合。通过这种方式，MVC应用程序可以像常规LINQ查询一样针对WCF数据服务投影数据。听起来很优雅，但我想听听另一种意见

---

有什么想法吗？如果你是我，你会怎么做？我需要一个优雅而实用的解决方案。

这里有一篇博客文章，其中包含nuget解决方案的一部分以及OData的一个愚蠢的怪癖，他们需要绕过它。实际上，他们有一个OData服务用于基于搜索的查询，而WCFSOAP用于基于Web的Soap。另一种选择是在后端使用MVCWebAPI，并生成一个REST接口，当然，通过它WebAPI ODataQueryable magic。缺点是AFAIK.netrest消费代码有点垃圾。另外，生成每个服务操作需要更多的工作。使用WebAPI而不是WCF有什么缺点吗？我是说，从消费者的角度来看。是的……正如我所说。WebAPI用于创建丰富的REST接口。net框架还没有产生一个好的REST客户端库。WCF数据服务客户端与我上次检查的WebAPI不兼容，这非常糟糕，因为它是我所知道的“最好的”LinqToOData提供商。