如何避免WCF中的大型通信类？

Question

我的理解是，所有合同实施代码必须属于单个类，显然可能变得非常大。我该如何避免这种情况？我真的更喜欢让几个小班做与客户沟通的一部分而不是一个庞然大物的班级。

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

Answer 1

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

与任何其他API开发一样，您不希望/不需要在同一个包中的所有位置。

Answer 2

首先，如果您的合同很大，他们可以重构为更具体的服务合同吗？

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

Answer 3

如果您可以从根本上更改代码，则可以只公开一个与请求/响应消息一起使用的端点。这种方式可能有一个单一的端点和一个服务定义，它接受（可能派生的）请求消息并返回响应消息。然后，您进入服务的接口只是一个单一的方法，在服务器端实现中，您可以将该请求对象路由到可能使用请求消息上的元数据的实际服务实现（可能由工厂确定）（或者甚至是'type- name）定义被调用的服务。

所以，你的终端服务接口只有这样的方法：

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

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

Answer 4

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

你的界面应该尽可能小（做好一件事）。但如果有必要，你的门面可以召唤多个班级。

Answer 5

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

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

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