在 .NET WCF 服务中组织大量方法的好方法是什么？答案

【问题标题】：What is a good way organize large number of methods in a .NET WCF service?在 .NET WCF 服务中组织大量方法的好方法是什么？
【发布时间】：2023-04-04 01:38:02
【问题描述】：

我目前正在开发一个在接口中定义了大量方法的 WCF 服务。这些方法中的大多数都是简单的 CRUD 操作，带有一些使用实体框架的逻辑，并且可以很容易地拆分为功能区域。只有一个文件接近 1K 行代码，我想将其拆分为可维护性。我正在考虑以下几点：

将服务文件拆分为部分类。但它仍然是具有大量代码的单个类。不过，我想这真的不是问题。
只有一个类实现了具有标准错误处理和 ObjectContext 创建/销毁的服务接口，但将调用路由到静态帮助程序类。我以前这样做过，但不知怎的，我觉得它不干净。

另外，最好是按功能区域分割，还是按 CRUD 方法（将所有人聚集在一起、一起创建等）分割。

在处理 WCF 服务时，这一定是一个非常常见的问题。组织 WCF 服务方法的好方法是什么？

更新

最后，我决定将服务调用传递给内部静态类。

【问题讨论】：

这取决于方法的性质 - 它们是否易于分组字节函数？他们有相似之处吗？想要将它们拆分的原因是什么——可维护性、可更新性等等。答案会影响建议。
它们可以很容易地按功能区域进行分组。拆分它们的原因是为了可维护性。
大多数时候你开始考虑使用部分类，因为你的类变得太大了，你知道是时候重构了..

标签： .net wcf

【解决方案1】：

如果可以按功能区域对操作进行分组，则它们应该是单独的服务，因为与任何其他类一样，服务应该具有单一职责 = 单一功能区域。

通常，如果您的服务有很多操作，那么是时候考虑拆分它了。此外，大多数情况下，WCF 服务只是围绕某些逻辑进行包装，因此您可以创建其他类的实例来包装您的逻辑或在服务操作中使用静态类。

编辑：

一般来说，我反对使用部分类来破坏一个大类——在我看来，它不会提高可维护性。一旦一个类太大以至于您正在寻找将其分解为多个文件的解决方案，这已经意味着重构应该早就完成了。在最坏的情况下，当你的班级做得太多时，我们可以称之为反模式：God object。

【讨论】：

我一般会同意。但是，我可以看到，在 Web 服务的情况下，可能会有这样做的情况，我认为它不一定倾向于上帝对象。在内部类中，这绝对是错误的。
@Schroedingers 猫：这取决于。如果您的服务只是包装了一些其他逻辑，并且它从一个功能区域公开方法，那么即使是具有很多方法的大型类也可能有意义。但是，如果服务实际上是从多个功能区域执行逻辑，那么它与内部类一样糟糕。

【解决方案2】：

为了可维护性，使用部分类似乎是一个不错的选择。如果它们在功能上被拆分，那么可维护性会得到提高，因为您应该只需要查看其中的一两个类。

根据您的回答，仍然存在一个包含许多方法的大型类这一事实并不是真正的问题。它应该是可维护的。

但是，跟随@Ladislav，将它们分成单独的服务对您有任何价值吗？我假设不是，否则你会那样做。

【讨论】：

我认为拆分成不同的服务没有任何价值。目前，方法并不多，但代码开始增长，我想在它变得太大之前重构。
也许是时候分道扬镳了。但是你比我更了解你自己的代码和环境，所以这是你的决定。