I am usually working with WCF services that uses single instance context mode. Also service contract and behavior is in a WCF service Library.
If the service is hosted as a Windows Service or a Web service, they get their own projects that references the WCF service library. I like to keep this WCF service library running (for simply debugging with WCF Test Client) but it requires too much effort when I try to resolve dependencies through the behavior class.
Using Castle Windsor, I also have to make additional configuration for Castle Windsor WCF Integration Facility. I am just trying to resolve the object graph on service startup and I feel like it shouldn't be this hard.
I thought, since behavior instance is created only once I should be able to use it as the composition root. I can provide all dependencies using a single object and resolve it from the container like this:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
public class SampleService : ISampleService, IDisposable
{
private readonly IServiceManager _serviceManager;
private readonly IWindsorContainer _container;
public SampleService()
{
_container = new WindsorContainer();
_container.Install(new ServiceInstaller());
_serviceManager = _container.Resolve<IServiceManager>();
}
public string GetMessage()
{
return _serviceManager.GetMessage();
}
public void Dispose()
{
_container.Dispose();
}
}
I know it's a bad idea to explicitly ask the container to resolve a dependency but this saves me from so much trouble. I get to keep the default WCF configuration, I can run the WCF service library for debugging since I have a default constructor now. I also don't have to use Castle Windsor WCF integration Facility which was missing documentation last time I checked.
I guess Castle Windsor WCF integration Facility offers more features but I just want to resolve the dependencies. Is this approach likely to cause some problems? I haven't seen anyone do it like this so I would like to know if this would be legitimate use.