i am searching right write up why we need to use interface as Service contract in WCF. i got this url Why does .net WCF Service require the Interface and from here i came to know that we can write service contract attribute on class instead of interface.
[ServiceContract]
public class TheService
{
// more stuff here
}
<services>
<service name="YourServiceName">
<endpoint address="" behaviorConfiguration="httpBehavior" binding="webHttpBinding" contract="TheService"/>
</service>
</services>
but very disappointed that not getting all the valid reason like why people often use interface as service contract ?
so just tell me all the advantage we get when we use interface as service contract. so looking for all the valid point for using interface as service contract. so give points with example scenario too because for better understanding. thanks
As you have demonstrated - you don't need to define an interface for a service contract to get it working. However, arguable in doing so, your class is violating the principle of Single Responsibility (granted this is officially an OO principle - but in my opinion it is one of those universal principles that seems to be a good idea everywhere).
The service contract acts as the "contract" (duh!) between the publisher of the service and the clients that consume it. As such, once you have clients consuming it, you need to be very careful about any changes you make - especially if the clients may be third parties over which you have no control. In accordance with the "Single Responsiblity Principle", defining an interface that represents the contract allows you let this interface have responsibility for the public API, separating it from the implementation.
[ServiceContract]
public interface ILoggingService
{
[OperationContract]
void LogMessage(string message);
}
This implementation is a relies of the fact that all clients connect to the same instance:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class SingletonLoggingService : ILoggingService
{
void LogMessage(string message)
{
}
}
This implementation give you a new instance of the service for every call to it:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class SingletonLoggingService : ILoggingService
{
void LogMessage(string message)
{
}
}
The advantage of the interface, is that I can mess around with the implementation as much as I like (including it's instancing mode, concurrency, it's behaviour under client sessions, namespace, the name of the class etc.), and not have to worry that I'm potentially breaking any clients.
Agreed - there are ways to maintain backwards compatibility even if you define the service contract to be the class - but it's far more error prone and you are more likely to forget something. Separating the public API and it's implementation leads to cleaner code, and a smaller risk of developers making mistakes.