WCF 服务契约设计。用例 Controller 合适吗？

Question

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

这是我的问题。我继承了一个产品，它的设计非常灵活，填充(silverlight)表单上的几乎每个组合框和文本 block 都需要服务请求。有些屏幕需要多达 15 个单独的请求才能填充!

现在，我已经在很多场合使用 WCF Web 服务，并且将服务契约(Contract)拆分为小的离散操作从来没有太大的打击，..遗憾的是，这个项目的情况并非如此。所以这让我想知道......

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

1. 获取投诉类型
2. 获取客户类型
3. 获取区域详细信息
4. 等等...

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

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

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

Answer 1

我觉得你的想法很不错。

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