Tuesday, September 16, 2008

Note on WCF behavior extension element

As described here: about configuration errors when defining behavior extensions, there is a bug that makes it necessary to fully specifiy the class and assembly name in your behavior extension:


<?xml version="1.0" encoding="utf-8"?>
<!-- configuration, servicemodel etc. left out for clarity-->
<extensions>
<behaviorExtensions>
<!-- Because of a bug in .NET framework you need to fully specify the behavior class and assembly
-->
<add name="springBehavior"
type="AgileSquad.Wcf.Spring.SpringServiceBehavior, AgileSquad.Wcf.Spring, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a44c692614ed00fa"/>
</behaviorExtensions>
</extensions>

Saturday, September 13, 2008

Update on WCF service dependency injection using Spring.NET

I have just uploaded the code that I use for DI in combination with WCF, using Spring.Net.
(better late than never!)

It's up on http://code.google.com/p/agilesquadblog/.
When you svn checkout it is in the AgileSquad.Wcf subfolder.

The instance provider itself is basically a copy/paste out of Oran Dennison's blog.
I have only changed the ReleaseInstance method to dispose of the instance (the service implementation) if it implements IDisposable:

public void ReleaseInstance(InstanceContext instanceContext, object instance)
{
IDisposable disposable = instance as IDisposable;
if(disposable!=null)
{
disposable.Dispose();
}
}

Additional to that the source code includes a working example (visual studio 2008 solution) of the instance provider, test service and configuration.
It includes unit tests to test the spring instance provider.

It also includes some interfaces that I use to abstract the use of WCF channel factory proxies and generated client classes.

The idea behind that is that I don't want my code to reference implementation directly, cause it makes testing more difficult.

So instead of something like:

using (var generatedWcfClient = new GeneratedWcfClient("endPoint"))
{
generatedWcfClient.SendMessage(message);
}

I use something like:

using (IServiceProxy<IMyService> proxy = factory.CreateProxy())
{
proxy.Service.SendMessage(message);
}

In my Service Consumer code. (The factory in the above example is injected through DI of course, see the code)

That means that the code that uses the proxies can be easily configured to use mock or in-memory implementations of the interfaces. It also decouples the use of the specific solution for communicating with a service (WCF in this case). The chance that I will change to some other implementation than WCF is obviously very small. But for testing and decoupling it is great in my opinion. It also decouples the choice of using a generated client or a channel factory.

Check out the code for more details.

The code also includes a ServiceTestEnvironment class that I use to easily test WCF Services. It hosts the WCF Service in a ServiceHost, and allows the unit test to call the service using a proxy and SetUp and TearDown the "environment". In the Test project I use the above mentioned IServiceProxy and IServiceProxyFactory interfaces. The ChannelFactory implementation is used, as a generated proxy would start conflicting (ambiguous references)with the service code because you would have to reference both the client and the server in this way of testing.

Firefox

I just found out my blog layout looks really weird on Firefox 3. Anybody any ideas?