making a WCF REST stand-alone service exe from scratch – part 2 of 4, extract a service contract interface

Extracting out an interface

In Part 1 we created the base WCF service inside a console app then showed it working from a web browser.  That’s nice, but it’s There’s one non-minimal change I wanted to get included here since I think it’s something most any WCF app will do – use a ‘real’ interface for the service contract.  There’s a few nice benefits of having the service contract be an interface instead of the actual concrete type like we did above:

  • We can move the WCF attributes (ServiceContract, WebGet, etc) into the interface and leave our service as just an implementation
  • We can put the interface in an assembly that we share with clients without having to share the actual service code with them
  • (biggest one IMHO) we get to use ChannelFactory to call our WCF REST service 🙂

ChannelFactory is an extremely useful class that lets you deal with the WCF service as an API (through the service contract interface) instead of dealing with any of the underlying mechanics of how to talk to it or having to generate a proxy (using svcutil or add service reference or whatever).  You generally just create a factory, call its CreateChannel which returns an instance of your interface, and then use it as you would any other “normal” interface, just like it was a local object:

image[104]

However, one of ChannelFactory’s requirements is that you’re using an actual interface to talk to the service.  Given what it does (CreateChannel returning an instance of the generic type you provide), hopefully that makes sense, since without this restriction the CreateChannel would need to return back an instance of the actual service class (!)

So, if you try to use ChannelFactory with the code as it is now, it’ll throw since we’re specifying the type to the factory as the actual service class (since we currently lack a separate contract interface)

 image[107]

So, lets extract out that service contract interface now.

While we would normally move it to another assembly that would be shared between the client and server, we’ll skip creating another class library for now and just do it in the same project.

I’m going to let ReSharper do the extract interface for me:

image[110]

However, it doesn’t do quite what I wanted – it duplicated the WebGet attribute (instead of only keeping it in the interface) and didn’t do anything with the class-level attributes at all.  So, I manually move those over after the extract, so we end up with a class that just implements the interface:

public class MyService : IMyService
{
    public string AnswerBack(string something)
    {
        return "You said: " + something;
    }
}

And an interface that includes the WCF bits:

[ServiceContract]
public interface IMyService
{
    [WebGet(UriTemplate = "say/{something}")]
    string AnswerBack(string something);
}

Switching the service contract to the extracted interface

Now that we have this separate interface, we need to go change the service endpoint to use this new interface as the contract.  First, rebuild so we’ll be able to just browse to the new contract :)  Then, open the config again (if you closed it)

 image

Now when browsing into the built exe, I see the interface we just extracted, and can choose that as the service contract:

image[116]

(Yes, I could have just edited the xml and added the ‘I’ but I wanted to show this method of doing so)

image[119]

Advertisements

2 thoughts on “making a WCF REST stand-alone service exe from scratch – part 2 of 4, extract a service contract interface

  1. Pingback: making a WCF REST stand-alone service exe from scratch – part 3 of 4, creating client configuration « James Manning's Blog

  2. Pingback: making a WCF REST stand-alone service exe from scratch – part 4 of 4, separating out the client and interface « James Manning's Blog

Comments are closed.