views:

158

answers:

1

I'm using a UserNamePasswordValidator in WCF along with Unity for my dependency injection, but since WCF creates the instance of the UserNamePasswordValidator, I cannot inject my container into the class. So how would one go about this?

The simplest solution I can think of is to create a static proxy/wrapper class around a static instance of a UnityContainer, which exposes all the same methods... This way, any class can access the container, and I don't need to inject it everywhere.

So I could just do UnityContainerWrapper.Resolve() anywhere in code. So basically this solution solves 2 problems for me, I can use it in classes that I'm not creating an instance of, and I can use it anywhere without having to inject the container into a bunch of classes.

The only downside I can think of is that I'm now potentially exposing my container to a bunch of classes that wouldn't of had access to the container before. Not really sure if this is even a problem though?

+1  A: 

Yes, this downsite is realy bad, and you should avoid it. In your case you can do something like this

public class CustomUserNameValidator : UserNamePasswordValidator
    {
        public static CustomUserNameValidator Current {
            get; private set;
        }

        public CustomUserNameValidator() {
            Current = this;
        }

        public override void Validate(string userName, string password)
        {
            throw new FaultException("No pasaran");

        }

        [Dependency]
        public ISomeService Service {
            get; set;
        }
    }

It will be created only once for service when service host is created, so you should write following code

 using (ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService))) //here it will be created
            {
                container.BuildUp(CustomUserNameValidator.Current); //here you can inject all you need
             }

This is just inverted idea with static wrapper of the unity container :)

er-v
I'm hosting through IIS, so I'm guessing I could do the BuildUp in the constructor of the service contract. But there's still a downside to this as well, you have to publically expose your service... But I guess that's a lot better than exposing the entire container.
Dannerbo
On another note... Since I'm using a config file to map all my objects for Unity, is my original static idea still a concern?Assume I don't use a static wrapper class around a unity container instance, I could still create a new UnityContainer anywhere in code and configure it using the config file and create any objects I wanted. So I'm not sure the UnityContainerWrapper idea is even creating an "issue", it's just making an existing issue more noticable? If that makes sense...
Dannerbo
probably, you have several assemblies, but only one is Unity aware - the most highlevel, so other can't create unitycontainer at all.Second thing is lifetime management. I's realy a big risc to create two containers with singletons, becouse you can get the whole other behaviour then you expect. So this is sort of conventional things, but it make such a scenario very unlikable.
er-v
I do agree, having just one assembly unity-aware would be nice... But in reality, aren't none of them?... Unless you're using strictly constructor injection? Because you have to tag all your dependencies with the [Dependency] attribute... So you have to reference the Unity assemblies anyway? Thoughts?
Dannerbo