我想对您采取以下措施。
我们将SOA视为解决我们所遇到的一些概念性问题的方法。我们不想多次构建相同的逻辑。因此，想要制作一些WCF服务，让不同的客户通过这些服务（甚至是Apple应用程序）检索数据。理想的情况是，客人尽可能地瘦，只关心表达。应该在WCF服务中处理所有业务逻辑和数据访问。
现在我的老板对此进行了调查，他最大的担忧基本上是我们陷入了混乱。他想象我们将为我们想要在数据库上执行的每个查询定义一个新方法，粗略地说。
所以喜欢：
所以他的想法是让cliënts构建查询并将其发送到WCF服务。 WCF服务执行查询，应用业务逻辑并返回结果。
我非常感兴趣的是你们可以提出的所有骗子或专业人士。提前谢谢你和我一起思考。
答案 0 :(得分：1)
这是SOAP样式的WCF服务吗？还是一个RESTful的？
无论哪种方式，我都很想拥有一组可选参数，通过这些参数可以发出请求，因此以RESTful服务为例，您将拥有一组额外的查询字符串参数来检索客户
e.g：
/顾客？ID = ID /客户？NAME = NAME /客户？STOREID = STORE ？/顾客ID = ID＆安培; withPersonalDetails =真安培; withPersonalDetails =假
当然，如果你主要通过ID获取
/客户/ {ID} /
将是一个很好的服务网址。
等效的东西可以在SOAPy端工作，请求中有一堆可以为空的参数。
优势在于客户只需知道它对客户的了解，并且可以将其提供给服务，该服务可以解决在检索客户之前计算查询所需的更复杂的任务。缺点是客户可能会制作没有提供足够信息的请求来获取客户。
但至少你不必担心客户提供无效的查询。
编辑：
至于为什么让客户提供查询是个坏主意 - 简单的答案是“它中断encapsulation，并引入了大量coupling”。答案很长，客户现在依赖于服务的实现细节。假设数据库的布局发生了变化，理想情况下，您希望尽可能少地进行更改 - 在一个封装良好的系统中，您必须更新持久层，并且可能没有其他内容。如果您的客户需要了解架构，您必须一直更新所有层，这显然很糟糕。
其次，如果客户端提供查询，那么您就是在暗示信任客户端 - 您已经掌握了大量工作来限制客户端可以做什么 - 想想如果有人开始冒充您的客户端并且任意运行会发生什么查询您的数据库 - eek！
第三，如果您需要修复查询，如果它在客户端，您必须更新客户端代码并将更新推送到所有客户端（有些人可能不会接受它，让这些用户留下错误）如果它是封装的在服务中你只需要解决问题。
第四，您的业务规则现在在哪里执行？在客户端。通过客户端和数据库之间的服务，您可以很好地控制所有业务规则。
如果您的客户正在制作数据库查询，它也可以直接附加到数据库 - 这在许多情况下都很好。但是，如果您希望能够在服务后面抽象数据库访问，在一个地方更新/修复您的业务规则，并限制您对恶意客户的责任，那么这是一个非常糟糕的主意。
（我确信还有其他几十个原因，在我早上喝茶之前，这些都是我的头脑。）
答案 1 :(得分：1)
你的老板可能是正确的，这或多或少会是什么样子但是
RetrieveCustomerWithPersonalDetailsButWithoutAddressById是不同的域模型，因此不会CustomerWithPersonalDetailsButWithoutAddress。object时的旧时间（或者如果您在VB6 COM中与我Variant一样老）。这意味着我们不想花费精力去接受理解我们领域的挑战。RetrieveCustomerByStoreId将不再需要，因为如果它与商店相关，则商店存储库负责提供商店。总而言之，如果您关注DDD，传递查询只会使设计变得非常草率。
答案 2 :(得分：1)
您认为使用WCF数据服务吗？ http://msdn.microsoft.com/en-us/library/cc668794.aspx
答案 3 :(得分：0)
所以他的想法是让cliënts构建查询并将其发送到WCF服务。 WCF服务执行查询，应用业务逻辑并返回结果。
它被称为Specification Pattern，它经常在DDD中使用。
一个采用规范参数的服务方法足以处理95％的对象请求。
WCF RIA Services中的 EntityQuery类就是一个例子，如何在客户端服务架构中使用规范模式。