Question

I’m trying to hock up WCF with dependency injection. All the examples that I have found is based on the assumptions that you either uses a .svc (ServiceHostFactory) service or uses app.config to configure the container. Other examples is also based on that the container is passed around to the classes.

I would like a solution where the container is not passed around (not tightly coupled to Unity). Where I don’t uses a config file to configure the container and where I use self-hosted services.

The problem is – as I see it – that the ServiceHost is taking the type of the service implementation as a parameter so what different does it do to use the InstanceProvider?

The solution I have come up with at the moment is to register the ServiceHost (or a specialization) an register a Type with a name ( e.g. container.RegisterInstance<Type>("ServiceName", typeof(Service);).

And then container.RegisterType<UnityServiceHost>(new InjectionConstructor(new ResolvedParameter<Type>("ServiceName"))); to register the ServiceHost.

Any better solutions out there? I’m I perhaps way of in my assumptions.

Best regards,
Michael

Answer 1

Use Constructor Injection to wire up your service implementation, just like you would with any other class.

Here’s a writeup on how to make WCF understand Constructor Injection.

The example in that answer demonstrates Poor Man’s Injection, but you can extrapolate from it and set up your UnityContainer instance in the ServiceHostFactory instead of a hard-coded dependency.

You pass the container instance all the way to the custom IInstanceProvider. Now you can use the container in the GetInstance method:

public object GetInstance(InstanceContext instanceContext)
{
    var serviceType = instanceContext.Host.Description.ServiceType;
    return this.container.Resolve(serviceType);
}