如何避免wcf中的大型通信类?

首先,如果你的合同很大,他们能重构成更具体的服务合同吗?

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

你可能想用 Inheritance ,这取决于yoru代码的结构。通常,您可以将所有代码分解成更小的片段、帮助程序、子例程等。

就像其他任何api开发一样,您不希望/不需要在同一个包中的同一个位置上的所有东西。

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

因此,您的终端服务接口将只有这样一个方法:

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

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

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

你的界面应该尽可能的小(做好一件事)。但如果有必要,您的门面可以调用多个类。

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

你的“一个类”代表你的“一个业务需要”。我们发现了一个很好的附带好处,如果我们团队的一个成员正在开发beam(我们的软件)的“accounting”部分,那么他们将签出文件“accounting\beamserver.cs”,团队的其他成员都不会受到影响。

编辑:同样,这个类应该 只有 包含方法签名(以及简单调用 base.Channel.DoSomething() …当然,任何数据结构都是它们自己的类文件(例如“person.cs”或“employee.cs”或其他)。