Home > Coding > WCF Proxies using Dependency Injection

WCF Proxies using Dependency Injection

Last time I noted that we use Dependancy Injection for a lot of things on my project and that one of the big pieces is the use of DI for our WCF Services. In this post I’ll cover what the benifits to this approach are and how we accomplished the task.

The benifits of writing our wcf service layer this way is the following:

1) It abstracts away the fact that it’s a service call. To the calling code, it’s just a DI interface.
2) Enables easy Mocking for unit testing (due to the DI container)
3) Easily swapping out what could be a service call or a local call with the opposite. This makes local integration testing and debugging easier.
4) Allows us to modify the interface without touching a bunch of projects. Before we did this, it took a while to right click and refresh the auto generated service reference every time an interface was updated.
5) Configure at runtime which services were in the container and what their settings were
a) This includes interface, URL, message size, graph size, etc.
b) One of our requirements was a centralized configuration system, not in the web config on 20 servers.

The con is that you aren’t using the autogenerated service reference; which means all of the nicities of the autogenerated async methods do not exist. We are handling async ourselves because of long running IO anyway, so this was not a big deterent for us.
The first step was creating a wrapper class that would properly dispose of the WCF channel. You cannot just have the interface implement IDisposeable and put that inside your using block, as it will call the remote dispose method, and not the local one.

 

As you can see, this function chooses the appropriote action depending on if the class is a WCF proxy or just a local interface.

The next step was to create some way to get the configuration data from a remote location. In our case that is a service (or a DB call); however, that remote locaction could be the web config, a seperate config file, whatever you come up with.

 

We originally started with just the first 4 properties; however, as we progressed through the project, we needed to adjust the rest of the settings as well.
After we had defined the settings we wanted to store, it was time to set up the dependancy injection container. For the most part, it’s a simple wrapper around the Unity container. The important setup is done in the regitration of the interface.

Unlike the normal use of DI, where we just tie a type to an interface, we want to tie an interface to a function call. We accomplish this in unity through the InjectionFactory class. The function CreateService is then called every time we make a Resolve<> call on the unity container for those registered interfaces.

 

This function uses reflection to new up a ChannelFactory<Interface> and call CreateChannel which will create a WCF channel with the configured binding and endpoint.

 

After some additional maintenance plumbing and creating some overrides for mockability; the end result is the is a singleton wrapper that can be used anywhere in your codebase to make WCF calls such as this:

 

The full code can be found here:  https://gist.github.com/3222717
How have you approached this problem in your own architectures?

 

 

Categories: Coding Tags: , ,
  1. No comments yet.
  1. No trackbacks yet.