1

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
}

config entry

<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

Community
  • 1
  • 1
Thomas
  • 33,544
  • 126
  • 357
  • 626
  • is there any tool exist which can convert web service to wcf without much manual work ? – Thomas Apr 10 '14 at 07:53
  • One reason might be that the interface makes for cleaner code as you can't instantiate it by mistake. Never given it much thought to be honest. Interface feels more logical to me for a service contract. I usually implement it in an SI/FL layer though. – Jontatas Apr 10 '14 at 08:02
  • Interface can be shared between the parties in the dedicated assembly. Having interface, you can also use Dependency Injection pattern to inject current implementation of the service. – Konrad Kokosa Apr 10 '14 at 08:09
  • The link you have shared in your question is best answer. "Best Practices". – Faizan Mubasher Apr 10 '14 at 08:11
  • from the link which i shared is not very clear that why people go for interface for service contract. – Thomas Apr 10 '14 at 08:14

1 Answers1

2

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.

Lawrence
  • 3,287
  • 19
  • 32
  • whatever reason here u highlighted those are valid point but not mandatory. many people say if we make our service a service contract instead of interface then our business logic will be expose to client but really do not understand how it will be possible at because when client will create proxy then proxy will never expose implementation detail at client side. so tell me what kind of problem will occur surely regarding service implementation. thanks – Thomas Apr 11 '14 at 13:11
  • i search goole lot to know the what actual problem may occur at the point of service security ? many people say if we make our service a service contract instead of interface then our business logic will be expose to client but really do not understand how it will be possible. do u have any idea about it? – Thomas Apr 11 '14 at 13:12
  • As I say in the first sentence - it certainly is not mandatory for everything to work. I'd be amazed if not using an interface resulted in some security breach. The points they may be getting at is that by using the class as the contract, you may inadvertently expose some implementation detail (like the name of the class), which may hint at how you could launch an attack on the service. For example, if my class was called "SqlLogger", then someone may try to launch a SQL injection attack. I believe you could get round this anyway by specifying a name on the ServcieContract attribute. – Lawrence Apr 11 '14 at 13:51
  • Although not mandatory from a functional point of view, I would argue that from a maintainability, and "risk" perspective, you should be using an interface. It leads to more concise and easier to understand code, which in turn reduces the risks of errors leaking in to a live environment. This can only be a good thing - and in some organisations this would be enough to ensure it becomes a "mandatory" policy ...! – Lawrence Apr 11 '14 at 13:55