views:

87

answers:

2

I am trying to create an interface wrapper for my IOC container so I do not have to have a dependency on a particular one. My problem is that some of the service classes I have take in a companyID which is a string. I want to make generic interface methods like

T Resolve<T>() where T is the service interface.

Right now I use StructureMap behind the scenes and know if the concrete constructor takes in the companyID so I will do something like this:

ObjectFactory.With("companyid").EqualTo("someCompanyID").GetInstance<ICompanyService>();

I wrap this sort of call in an interface method: ICompanyService GetCompanyService(string companyID)

The way I have it now, the application has to initialize StructureMaps config and the concrete class, that passes back the services, has to know a lot about the constructors. I would like for that not to happen and to make the wrapper generic. Is there a nice way, without having to add companyID to each method on the interface?

+2  A: 

Personally I don't really care about abstracting out MSUnity (My IOC container of choice). For me it's one step too far. It sounds like you are using structuremap specific features, which will make the abstraction harder.

Are you aware of the CommonServiceLocator project?. That has main methods two methods:

protected override object DoGetInstance(Type serviceType, string key) { }
protected override IEnumerable<object> DoGetAllInstances(Type serviceType) {}

Providing you stick to using these you can easily switch. Here's some more info.

RichardOD
I have SM abstracted out a bit, just not fully. I am looking at some Open source that made a wrapper, but it does not take into account primitives in the ctors.
CSharpAtl
@CSharpAtl- reconsider your design. Frameworks like these have to work with the lowest common denominator. You need to work out whether being able to switch out your IOC is more important than being able to use StructureMap specific features.
RichardOD
@RichardOD I agree.
pattersonc
+1 I hear you....just been trying to work on this issue, and looking at MVC Turbine which creates does something similar has be thinking again.
CSharpAtl
A: 

There is a DependencyResolver class in MvcContrib.

On the other hand, most of the time I just ref the IoC container from my app project only. For instance, I simply setup my classes for ctor injection and when I need to grab an instance (in the app project) I simply ask the IoC container for it. The IoC container can worry about filling in the ctor args but the objects are unaware of the IoC container. This way my app project is the only project that needs to ref the IoC container.

pattersonc