WCF without service contract interface is possible

Question

i was searching google to know that how we can easily convert asmx service to wcf and there i saw people write code like

this is my old asmx service

[WebService(Namespace="http://kennyw.com/sampleservices/")]
public class MyService : System.Web.Services.WebService
 { 
[WebMethod]
public string Hello(string name)
  { 
   return string.Format(“Hello {0}.”, name);

  }

}

convert to wcf

[ServiceContract(Namespace="http://kennyw.com/WCFservices/")]
[WebService(Namespace="http://kennyw.com/sampleservices/")]
public class MyService : System.Web.Services.WebService
 { 
[WebMethod]
[OperationContract]
public string Hello(string name)
   { 
    return string.Format(“Hello {0}.”, name);

   }

}

i saw when converting then people is not using service contract interface. how it will work because i know that when we develop wcf service then i have to write one service contract interface for single service. so looking for discussion that how possible to develop wcf service without service contract interface. thanks

Answer 1

The above will not work in case you do not specify a correct contract naming in your web.config.

In case your class without an interface is in the following namespace:

namespace Foo
{
    [ServiceContract(Namespace="http://kennyw.com/WCFservices/")]
    [WebService(Namespace="http://kennyw.com/sampleservices/")]
    public class MyService : System.Web.Services.WebService
    { 
        [WebMethod]
        [OperationContract]
        public string Hello(string name)
        { 
            return string.Format(“Hello {0}.”, name);

        }
    }
}

In this case the web config service configuration should look like

<services>
    <service name="YourServiceName">
        <endpoint address="" behaviorConfiguration="httpBehavior" binding="webHttpBinding" contract="Foo.MyService"/>
    </service>
</services>

Answer 2

Because the programming against interfaces is a good thing for several reasons:

• For example one of the very important reasons is that you can easily use it in unit test in a way that you can easily mock or stub it (and set expectations on it).

  IYourInterfaceMethods stub = MockRepository.GenerateStub();

  IYourInterfaceMethods mock = MockRepository.GenerateMock();

If you are in the big company, when you are not coding just for yourself and to get the JIRA task getting done, you are usually in a position to program for others, for your colleges. You are creating APIs for them, which they can use and reuse (so lower the costs for the company). In this case you should put the implementation of a service in a separate library and expose only the interfaces which they can then call, and reuse your master piece. But what happens in this case is that when someone is starting to use your service (which for example can send SMS, which costs money, or for example runs a 5 minutes long processing of some complicated calculation), he will need to be able to mock or stub it, if he wants to have a unit test for it. So your code must be testable and you can achieve it by exposing your functionality thru the interface. That way the user of your API can use simple frameworks that do not cost money (since you still can use other unit test frameworks that do not need to work with interfaces, but they are not free).

• If you put your interface in to a separate library, the users of your API can have only this library with interfaces that they use. And in case your interfaces are stable (do not change very often), they do not have to recompile their code and rarely have to redeploy their application (mobile, web, etc). In big companies the deployment of a new version can be dangerous. They love to stick to a golden plan: Do not fix it if it ain't broken. And what is the benefit for you? You can play with a concrete implementation as much as you like, fix bugs, fix this and that, refactor, delete…have fun in general, but not hurt anybody:)…

• There are also many other reasons to use interfaces, safety for a programmer etc.. But I think the above are the most important 2.

I hope I helped.