我目前正在使用界面中定义的大量方法来处理WCF服务。这些方法中的大多数都是简单的CRUD操作，只需使用实体框架的一些逻辑即可，并且可以很容易地将其分割为功能区域。只有一个文件接近1K行代码，我想分解它以提高可维护性。我正在考虑以下内容：什么是在.NET WCF服务中组织大量方法的好方法？
此外，根据功能区域或CRUD方法（组合在一起，共同创建等）更好地分割。
这在处理WCF服务时必定是一个非常普遍的问题。什么是组织WCF服务方法的好方法？
更新
最后，我决定通过内部静态类的服务电话。
如果操作可以按功能区域分组，则它们应该是单独的服务，因为与其他任何类别的服务应该有单一职责=单一功能区域。
通常，如果您的服务有很多操作，现在是时候处理它的分裂问题了。另外，大多数情况下，WCF服务仅包含一些逻辑，因此您可以创建包装逻辑的其他类的实例，或者在服务操作中使用静态类。
编辑：
通常我反对使用部分类，打破了大类 - 在我看来，这并不能提高可维护性。一旦一个类如此之大，以至于你正在寻找将其分解成多个文件的解决方案，那就意味着很久以前就应该重构了。在最糟糕的情况下，当你的班级真的做得太多时，我们可以称之为反模式：God object。
我一般会同意。但是，我可以看到，在Web服务的情况下，可能会出现这种情况，我认为它不一定倾向于上帝对象。在内部课堂上，这绝对是错误的。 –
@Schroedingers猫：这取决于。如果你的服务只是围绕其他逻辑进行封装，并且它暴露了一个功能区域的方法，那么即使是拥有很多方法的大类也是有意义的。但是，如果服务实际上从多个功能区域执行逻辑，那么它与内部类一样糟糕。 –
为了可维护性，使用部分类似乎是一个不错的选择。如果它们在功能上分离，那么可维护性会提高，因为您只需要查看这些类中的一个或两个。
事实上，仍然有一个巨大的类与许多方法不是真正的问题根据你的答案。它应该是可维护的。
但是，要遵循@Ladislav，将它们分离为单独的服务有什么价值吗？我不假设，否则你会这样做。
我没有看到分裂成不同服务的任何价值。目前，这不是很多方法，但代码开始增长，并且我想在它变得太大之前重构。 – Mas
这可能是想法分裂的时候。但是你比我更了解自己的代码和环境，所以它是你的决定。 –
这取决于方法的性质 - 它们是否易于分组byt函数？他们有相似之处吗？什么是想要分裂它们的原因 - 可维护性，可更新性或什么。答案会影响建议。 –
他们可以很容易地按功能区分组。拆分它们的原因是可维护性。 – Mas
大多数时候你开始考虑使用部分类，因为你的班级变得太大，你知道是时候重构了。 – codymanix