如何避免 WCF 中的大量通信类？答案

【问题标题】：How can I avoid huge communication classes in WCF?如何避免 WCF 中的大量通信类？
【发布时间】：2010-03-15 10:16:23
【问题描述】：

我的理解是，所有合同实现代码都必须在一个类中，这显然会变得非常大。我该如何避免这种情况？比起一个庞然大物的班级，我真的更喜欢让几个小班级来做与客户沟通的一部分。

我能想到的唯一想法是使用由partial 拆分的单个类实现的多个接口，但我认为这并不能真正解决问题。

【问题讨论】：

标签： wcf

【解决方案1】：

您可能希望使用Inheritance，具体取决于 yoru 代码的结构。通常你可以将所有代码分解成更小的部分、帮助程序、子例程等。

就像任何其他 API 开发一样，您不希望/不需要在同一个包中的同一个地方的所有内容。

【讨论】：

【解决方案2】：

首先，如果您的合同很大，是否可以将它们重构为更具体的服务合同？

合约实现类可以实现为入口点方法。您始终可以对实现进行建模并定义适当的抽象，并让您的服务合同实现类调用这些内部实现。

【讨论】：

+1 完全正确 - 没有一个庞大的 über 服务合同 - 将其分成可管理的块。那么服务实现也不会太大！
多个合约意味着多个连接，对吧？我宁愿避免这种情况。
每个都必须托管在不同的地址，因此如果这就是您的意思，则需要不同的代理连接。如果您试图避免这种情况，请重构您的内部实现以使用其他答案中建议的继承或外观模式。
最后这是我用的，所以接受了，即使它不是我最初要求的。

【解决方案3】：

如果您可以从根本上更改您的代码，您可以只公开一个处理请求/响应消息的端点。这样可以有一个端点和一个服务定义，它接受（可能派生的）请求消息并返回响应消息。然后，您到服务的接口将只是一个方法，并且在服务器端实现中，您可以将该请求对象路由到实际的服务实现（可能由工厂确定），可能使用请求消息上的元数据（甚至它的类型） name) 来定义正在调用的服务。

因此，您的最终服务接口将只有这样的方法：

public interface IServiceRequestor
{
  Response ProcessRequest(Request request);
}

这允许您处理可能无限数量的公开服务，而不必知道它们在编译/开发时将是什么，并且还避免了定义可用服务调用的服务方法的扩散

【讨论】：

这当然很激进。但是组合相似方法的总体思路是好的。

【解决方案4】：

“单一类”通常是一个门面，只是一个通信前端。
所以你应该不在服务实现者中实现你所有的逻辑。

而且你的接口应该尽可能小（做好一件事）。但如有必要，您的外观可以调用多个类。

【讨论】：

是的，当然，但是班级仍然很大，所以我想以某种方式将其拆分...
这意味着你有一个“相当大”的界面，可能是一个设计问题。

【解决方案5】：

我们有大约 60 个名为“BeamServer.cs”的部分文件，每个文件都位于对应于该文件中函数用途的子文件夹中。用于我们程序同一区域的任何帮助程序类（或其他帮助程序文件）也位于该文件夹中。

您的“一个类别”代表您的“一个业务需求”。我们发现了一个很好的附带好处，如果我们团队中的一个成员正在处理 BEAM（我们的软件）的“会计”部分，那么他们会检查文件“Accounting\BeamServer.cs”，其余的都没有团队的成员将受到影响。

编辑：此外，类应该只包含方法签名（以及简单调用base.Channel.DoSomething()的包装函数......任何数据结构当然都是它们自己的类文件（例如“ Person.cs”或“Employee.cs”或其他）。

【讨论】：

我继续尝试了部分类，但遗憾的是，VS08 并没有很好地支持它，所以我有点放弃了这个想法。 :(