¿Por qué el servicio .NET WCF requiere la interfaz

Question

? A diferencia de la implementación de asmx, el wcf requiere que implemente su interfaz. No entiendo muy bien la razón detrás de ese diseño. La interfaz es un contrato entre 2 clases ... Dicho esto, ¿con qué frecuencia tiene 2 servicios wcf que satisfacen la misma interfaz pero que se implementan de manera diferente?

Otro comentario, el MSDN recomienda encarecidamente que hacer esto:

MyService service = new MyService(); 

    try { 

     service.DoWork(); 

    } 
    catch(Exception) {} 
    finally { 
     service.Close(); 
    } 

Así que digamos que si estoy para inyectar mi servicio con el uso de su interfaz de la siguiente manera:

public MyComponent : IDisposable 
    { 

     readonly IMyService service = null; 

     public MyComponent(IMyService service) { 

      this.service = service; 

     } 

     public DoWork() 
     { 
      //some additional code. 
      this.service.DoWork(); 

     } 

     public void Dispose() 
     { 
      //The Interface does not have the Close method, 
      //So doing this defeats the whole purpose of polymorphysm 
      (this.service as MyService).Close(); //Silly. 
     } 
    } 

¿Cómo se toma la ventaja de la interfaz con WCF?

Answer 1

No, WCF NO requiere para tener una interfaz e implementarlo.

Es sólo acepta generalmente mejores prácticas para hacerlo - pero usted no tiene que , si usted no desea.

Si lo desea, puede poner su [ServiceContract] en una clase concreta que tenga varios métodos de servicio [OperationContract]; no hay nada que lo impida.

Pero de nuevo: es una buena práctica generalmente aceptada y predicada utilizar una interfaz para separar el contrato real como una interfaz (por lo que puede, por ejemplo, simularlo para realizar pruebas, etc.).

Answer 2

Usted puede crear un servicio WCF sin necesidad de utilizar una interfaz:

[ServiceContract] 
public class TheService 
{ 
    // more stuff here 
} 

Dicho esto, se recomienda para separarlos. Separar el contrato de la implementación puede brindarle algunas ventajas diferentes:

• Puede colocar las interfaces en un ensamblaje separado. Este conjunto puede usarse con cualquier código que necesite conocer sobre la interfaz, pero no necesariamente sobre la implementación. Lo he usado a veces para construir una especie de pasarela de servicio que envuelve la comunicación con el servicio.
• Puede hacer que una clase implemente más de una interfaz. Esto significa que puede exponer la misma clase implementada de diferentes maneras utilizando diferentes interfaces en los puntos finales WCF.

Hay otras razones, pero estas vienen inmediatamente a la mente.

Answer 3

En realidad, incluso MSDN concede de vez en cuando que la formalidad de las interfaces no siempre puede ser "lo que hay que hacer":

http://msdn.microsoft.com/en-us/library/ms733070.aspx

"La ventaja de crear sus servicios mediante la aplicación ServiceContractAttribute y OperationContractAttribute directamente a la clase y los métodos en la clase, respectivamente, es la velocidad y la simplicidad ".

Answer 4

en las interfaces de dotnet se utilizan para describir el comportamiento. WCF, servicios web y comunicación remota toda esta tecnología utiliza el comportamiento RPC (llamadas a procedimiento remoto). en RPC debe haber un enlace común compartido por el cliente y el servidor.

si utiliza clases en lugar de interfaz, también debe compartir el archivo dll resultante con el cliente. por lo tanto, su lógica va al lado del cliente, lo cual no es una buena práctica. es por eso que estamos usando interfaces.

Answer 5

Si crea un servicio sin interfaz, perderá la capacidad de crear un canal sobre la marcha en su código. Entonces, la única manera en que puede acceder al servicio es agregando una referencia de servicio.

Intentó con la plantilla de servicio WCF VS 2015 predeterminada; marcó la clase de servicio con ServiceContract y los métodos con OperationContract atributo. La implementación de la interfaz IService1 se elimina (no se implementa la interfaz).

[ServiceContract] 
public class Service1 
{ 
    [OperationContract] 
    public string GetData(int value) 
    { 
     return string.Format("You entered: {0}", value); 
    } 

    [OperationContract] 
    public CompositeType GetDataUsingDataContract(CompositeType composite) 
    { 
     if (composite == null) 
     { 
      throw new ArgumentNullException("composite"); 
     } 
     if (composite.BoolValue) 
     { 
      composite.StringValue += "Suffix"; 
     } 
     return composite; 
    } 
} 

Con este cambio no podemos crear un canal de proxy sobre la marcha que intenté con la parte inferior del código.

BasicHttpBinding myBinding = new BasicHttpBinding(); 
    EndpointAddress myEndpoint = new  EndpointAddress("http://localhost:59420/Service1.svc"); 
    // InvalidOperationException is thrown as below line 
    // Error message "The type argument passed to the generic ChannelFactory class must be an interface type" 
    ChannelFactory<Service1> myChannelFactory = new ChannelFactory<Service1>(myBinding, myEndpoint); 
    // Create a channel. 
    Service1 wcfClient1 = myChannelFactory.CreateChannel(); 
    Console.WriteLine(wcfClient1.GetData(1)); 
    Console.ReadKey(); 

Si utilizamos y aplicamos interfaz de la siguiente

public class Service1 : IService1 

continuación, se ejecuta código de abajo sin ningún problema. Ahora Service1 ahora se reemplaza por la interfaz IService1 mientras se crea el objeto ChannelFactory.

ChannelFactory<IService1> myChannelFactory = new ChannelFactory<IService1>(myBinding, myEndpoint); 

Este es el aspecto más importante si su cliente utiliza ChannelFactory en lugar de ServiceReference para acceder al servicio.