¿Cómo puedo evitar grandes clases de comunicación en WCF?

Question

Según tengo entendido, todo el código de implementación de contratos tiene que estar en una sola clase, que puede llegar a ser muy grande, obviamente. ¿Cómo evito esto? Realmente prefiero tener unas pocas clases pequeñas haciendo una parte de la comunicación con los clientes que una única clase gigantesca.

La única idea que se me ocurre es usar múltiples interfaces implementadas por una sola clase dividida por partial, pero no creo que esto realmente resuelva el problema.

Answer 1

Primero, si su contrato es grande, ¿pueden ser refactorizados en contratos de servicio más específicos?

La clase de implementación del contrato se puede implementar como método de punto de entrada. Siempre puede modelar la implementación y definir la abstracción apropiada y hacer que su clase de implementación de contrato de servicio llame a esa implementación interna.

Answer 2

Esa 'clase individual' generalmente es una fachada, solo un front-end de comunicación.
Por lo tanto, debe no implementar toda su lógica en el Implementador de servicios.

Y sus interfaces deben ser lo más pequeñas posible (haga 1 cosa bien). Pero si es necesario, su fachada puede invocar múltiples clases.

Answer 3

Es posible que desee utilizar Inheritance, dependiendo de la estructura del código yoru. Por lo general, puedes dividir todo el código en piezas más pequeñas, ayudantes, sub-rutinas, etc.

Es como con cualquier otro desarrollo de API, no quieres/no necesitas todo en el mismo lugar en el mismo paquete.

Answer 4

Tenemos aproximadamente 60 archivos parciales llamados "BeamServer.cs", cada uno en una subcarpeta que corresponde al propósito de las funciones en ese archivo. Cualquier clase de ayuda (u otros archivos auxiliares) que sean para la misma área de nuestro programa reside en esa carpeta también.

Su "clase única" representa su "necesidad de una empresa". Encontramos un buen beneficio adicional en el sentido de que si uno de los miembros de nuestro equipo está trabajando en la parte de "contabilidad" de BEAM (nuestro software), entonces verificaría el archivo "Accounting \ BeamServer.cs" y nada del resto del equipo se vería afectado.

EDIT: Además, la clase debe única contener las firmas de los métodos (y funciones de contenedor que simplemente llaman base.Channel.DoSomething() ... cualquier estructura de datos serían, por supuesto sus propios archivos de clase (como "Person.cs" o " Employee.cs "o lo que sea).

Answer 5

Si pudiera cambiar su código fundamentalmente, podría exponer solo un punto final que funcione con los mensajes de solicitud/respuesta. De esta manera podría haber un solo punto final y una única definición de servicio que toma un mensaje de solicitud (posiblemente derivado) y devuelve un mensaje de respuesta. Su interfaz en el servicio sería simplemente un único método y en la implementación del lado del servidor enrutaría ese objeto de solicitud al servicio real i Implementación (posiblemente determinada por una fábrica) posiblemente usando metadatos en el mensaje de solicitud (o incluso 'nombre de tipo') para definir a qué servicio se está llamando.

lo tanto, su interfaz de servicio final sería simplemente tener un método como este:

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

Esto le permite manejar un número posiblemente ilimitado de servicios expuestos sin necesidad de saber lo que van a estar en la compilación/hora dev , y también evitar una proliferación de métodos de servicio que definen las llamadas de servicio disponibles