WCF y herencia de interfaz: ¿es algo terrible de hacer?

Question

Mi aplicación tiene 2 "servicios", digamos que una es una calculadora básica (entera), y una es una calculadora de coma flotante. Los expreso como interfaces así:

public interface IBasicCalculator 
{ 
    int Add(int a, int b); 
} 

public interface IFloatingPointCalculator 
{ 
    double Add(double a, double b); 
} 

Quiero exponer estos a través de WCF. Lamentablemente, WCF parece estar estrechamente ligada a la noción de que cada operación posible que desee exponer debe pasar por una única interfaz de servicio: no puede compartir sesiones entre servicios, es engorroso desde el lado del cliente ya que necesita crear un proxy separado para cada uno, no parece haber ningún "sub-servicios", etc.

Por lo tanto, he deducido que necesito presentar una interfaz "combinada" (también se podría llamarla) una fachada), así:

[ServiceContract] 
public interface ICalculatorService : IBasicCalculator, IFloatingPointCalculator 
{ 
    [OperationContract(Name = "AddInt")] 
    new int Add(int a, int b); 

    [OperationContract(Name = "AddDouble")] 
    new double Add(double a, double b); 
} 

Si hago esto, entonces WCF expone dos métodos para el cliente, que se les puede llamar, y todo funciona realmente.

Sin embargo, "heredar las interfaces" parece ser desgarbado. Particularmente la newint Add y newdouble Add. Estrictamente hablando, new en un método indica que se oculta un método subyacente, que en realidad no estoy haciendo en absoluto. Puedo omitir el new, pero luego recibo advertencias del compilador que equivalen a "Creo que estoy ocultando este método, necesitas cambiarle el nombre a método o poner 'nuevo' en él".

Por lo tanto, esta es una cuestión de 2 partes:

1. ¿Estoy en la pista con mi 'combinar todo en una interfaz' lógica, o hay realmente una manera de exponer "sub-services" o "múltiples servicios vinculados" usando WCF?

2. Si esto es lo que hay que hacer, ¿hay una manera mejor?

Gracias!

Answer 1

Yo diría en general, no. Recuerde que está tratando con una tecnología de aplicación distribuida, no con una tecnología de objetos distribuidos, por lo que conceptos como la herencia no se aplican.

En general, no seguiría este camino, sino que tendría contratos específicos que representan la agrupación lógica de operaciones que desea exponer a través del punto final.

Answer 2

Acabo de descubrir que puedes exponer múltiples puntos finales (cada uno usando una interfaz diferente) al mismo servicio, y solo necesitas generar UNA lib de proxy en el cliente que da acceso a todos ellos, lo que resuelve mi problema enteramente.

Answer 3

Creo que lo que describes no es realmente una buena práctica. Claro, es factible implementar más de un contrato de servicio en un tipo de servicio, ya que es solo una cuestión de implementar múltiples interfaces.

WCF sin duda hace que sea viable admitir múltiples puntos finales que se comunican mediante URI únicos y contratos independientes. Sin embargo, el hecho de que la clase ClientBase solo acepte un tipo de interfaz de contrato, por ejemplo, implica que las clases proxy, incluso si están almacenadas en la misma lib, todavía necesitan implementar claramente una sola interfaz de contrato.

Si tiene éxito al crear solo una definición de clase proxy, me gustaría saber cómo logró lograr esto. Sin embargo, puedo estar malinterpretando tus necesidades. La implementación de diferentes clases de proxy le brinda la máxima flexibilidad porque los valores de OperationContractAtrribute como IsInitiating e IsTerminating probablemente serán diferentes para diferentes contratos. La combinación de las interfaces de dos contratos, como en su ejemplo, puede cambiar la forma en que atribuiría los métodos en el contrato del Servicio.