¿Cuál es una buena manera de organizar una gran cantidad de métodos en un servicio .NET WCF?

Question

Actualmente estoy trabajando en un servicio WCF con una gran cantidad de métodos definidos en la interfaz. La mayoría de estos métodos son simples operaciones CRUD con un poco de lógica utilizando el marco de entidad, y podrían dividirse en áreas funcionales con bastante facilidad. Solo hay un archivo que se acerca a 1K de líneas de código y me gustaría dividirlo para mantenerlo. Estoy considerando lo siguiente:

• Divida el archivo de servicio en clases parciales. Pero aún sería una clase única con un código de gran cantidad. Sin embargo, creo que esto realmente no es un problema.
• Tiene una sola clase que implementa la interfaz de servicio con el manejo de errores estándar y la creación/destrucción de ObjectContext, pero enruta las llamadas a las clases de ayuda estática. He hecho esto antes, pero de alguna manera no me parece limpio.

Además, ¿sería mejor dividir por área funcional, o por métodos CRUD (agrupar todo, crear juntos, etc.).

Esto debe ser un problema muy común cuando se trata de servicios WCF. ¿Cuál es una buena manera de organizar los métodos de servicio WCF?

actualización

Al final, decidí pasar las llamadas de servicio a clases estáticas internas.

Answer 1

Si las operaciones se pueden agrupar por áreas funcionales, deberían ser servicios separados porque el servicio como cualquier otra clase debería tener una sola responsabilidad = área funcional única.

Generalmente, si su servicio tiene muchas operaciones, es hora de pensar en su división. También lo más frecuente es que el servicio WCF sea solo envoltorio de alguna lógica para que pueda crear instancias de otras clases envolviendo su lógica o utilizando clases estáticas en sus operaciones de servicio.

Editar:

En general estoy contra el uso de las clases parciales para romper una clase grande - en mi opinión, no mejora la capacidad de mantenimiento. Una vez que una clase es tan grande que está buscando una solución para dividirla en varios archivos, ya significa que la refactorización debería haber sido hecha hace mucho tiempo. En el peor de los casos, cuando tu clase está haciendo demasiado, podemos llamarlo anti patrón: God object.

Answer 2

Para el mantenimiento, el uso de clases parciales parece ser una buena opción. Si se dividen funcionalmente, se mejora la capacidad de mantenimiento, ya que solo debe mirar una o dos de estas clases.

El hecho de que todavía hay una gran clase con muchos métodos no es realmente un problema sobre la base de sus respuestas. Debe ser mantenible.

Pero, para seguir @Ladislav, ¿tiene algún valor para separarlos en servicios separados? Supuse que no, de lo contrario hubieras hecho eso.