WCF 服务契约设计。用例控制器是否合适？答案

【问题标题】：WCF service contract design. Is a use case controller appropriate?WCF 服务契约设计。用例控制器是否合适？
【发布时间】：2011-04-06 05:55:24
【问题描述】：

首先，如果之前有人问过这个问题，我深表歉意，但我找不到任何可以直接回答这个问题的东西。

这是我的问题。我继承了一种产品，它的设计非常灵活，以至于填充（silverlight）表单上的几乎每个组合框和文本块都需要服务请求。有些屏幕需要超过 15 个单独的请求才能填充！

现在我曾多次使用 WCF Web 服务，并且将服务合同拆分为小的离散操作从未受到太大影响，..遗憾的是，这个项目并非如此。所以这让我想知道......

没有计划将服务暴露在我们自己的墙之外。没有计划为此特定服务编写另一个客户端。那么我不能在服务端写一个“用例控制器”吗？因此，在“创建投诉”屏幕中，而不是有一个请求列表，例如...

要填充表单，我只需要一个名为“GetCreateComplaintData”的操作合同。当只有一个客户端必须将所有这些请求聚合并同步为有意义的东西时，以如此粒度公开这么多操作似乎很疯狂。为什么不首先公开一些有意义的东西？

更重要的是，如果您不打算将服务 API 公开给第三方，这难道不是比公开数据库中表的 CRUD 操作更好的策略吗？

感谢所有帮助和意见。提前致谢。

【问题讨论】：

【解决方案1】：

我觉得你的想法还不错。

作为一种中间方式，您还可以考虑将多个 WCF 请求批处理为一个的方法。 over here 描述了这种方法以及如何对其进行编程。

【讨论】：

【解决方案2】：

我认为您首先必须确定性能问题的确切位置。 IIS 真的无法处理您发送给它的请求数量吗？或者是每个单独的请求都花费了太长时间，因为数据库无法提供您的数据，并且看起来 IIS 无法处理压力。

我不确定以下两种情况之间是否存在真正的区别：

当然，我不确定您的具体情况，但在性能方面，最好事先了解您优化的确切原因。

【讨论】：

连接数有差异。
我看到的不同之处在于，我发送/接收的标头数据几乎与实际有效负载一样多。此外，在 silverlight 客户端中同步这些调用被证明是一种真正的痛苦。
所有标题开销都可能是一个问题，我明白这一点。 Silverlight 应用程序的异步特性并没有让它变得更容易，我自己也遇到过一次。我想说的是，您应该事先确保您正在解决正确的问题。祝你的应用好运。

【解决方案3】：

业务逻辑之上的 WCF 服务应该暴露高级业务操作的外观，而不是低级 CRUD 操作。 CRUD 操作服务用于暴露数据（如 WCF 数据服务）。

【讨论】：

除了公开数据之外，Web 服务还能做什么？我同意这是一个坏主意，但从概念上讲没有真正的区别吗？我的意思是，..对于大多数位于 CRUD 操作之上的应用程序，有什么业务逻辑？
分布式接口不应该是健谈的。在最好的情况下，这意味着分布式系统的客户端应该能够通过单个 Web 服务调用执行单个操作，以减少往返。在您的情况下，该操作是“准备表格”。 WCF 公开的服务外观应该从 CRUD 操作中收集所有数据，并在单个响应中将它们发送回来。
同意所有观点。我只是说...对于很多“表单优于数据”的应用程序，两者之间没有太大区别。

【解决方案4】：

这是我对这一切的看法。答案一如既往，视情况而定。

以下是一些关于如何使用 WCF 构建 SOA 的实际示例。

我建议您阅读 Thomas Erl 和 Roger Sessions 的文章，这将使您牢牢掌握 SOA 的全部内容。

【讨论】：

【解决方案5】：

使用带有 WCF 的 CRUD 模式从数据库公开数据的最简单方法是使用 WCF 数据服务。除了要公开的模型之外，您实际上并没有在服务器端开发任何东西，如果您使用它来访问数据库，它也可以从 EF 模型中自动推断出来。

巴勃罗。

【讨论】：