Newbie (but sort of advanced) Dependency Injection questions...

SledgeHammer01

I use an MVVM / custom control library that I wrote myself. Right now it works like this at a high level: * all view models are derived from ViewModelBase * I have an attached Type property called ViewModel that gets specified something like: . . My library creates an instance of local:Test and sets the Window.DataContext equal to that instance. * At this point, all ViewModels must have a default parameterless constructor * ViewModelBase also has a static ServiceLocator I have not really used Dependency Injection before, but it is my understanding that my current code looks like this: public class Test : ViewModelBase { public Test() { ServiceLocator.GetService(); ServiceLocator.GetService(); } } vs. Dependency Injection which looks something like: public class Test : ViewModelBase { public Test(IFoo1 foo1, IFoo2 foo2) { } } at some point early in the start up, you are supposed to register the interface <-> implementation class mappings? So if I want to add DI support to my MVVM lib, it is my understanding that the ViewLocator needs to go through the params in the constructor and match up the interfaces with the classes that you registered. I am **NOT** interested in using a DI lib that somebody else wrote like Unity, etc. I am interested in knowing how they work and implementing my own. Seems like the requirement is that you have a single public constructor? Some libs I have seen add a custom attribute like [DependencyInjection] or [Ninject] to the one constructor that you want the DI to happen on? What is the best approach? Are these libs using reflection to go through the constructor params? Or some other cool mechanism for which I am unaware? I assume there is some kind of caching going on? Like, it only needs to go through the reflection once and then caches the interfaces and the order of which they are passed in? Last question for now... seems like ServiceLocator, you pass in the type and a class instance to register, but in DI, you pass in an interface type and a class instance type?

Abhinav S

I thought Unity was open source - why dont you have a look at the source code itself?

The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.

James McConville

hey, I just started taking a look at this myself. Try the following - takes you through building your own (if very simple IOC).. http://weblogs.asp.net/sfeldman/archive/2008/02/14/understanding-ioc-container.aspx[^] Hope that helps.

SledgeHammer01

Jesus... I can barely read that article :-D. The English on it is so poor! The guy is just randomly making up words as he goes along it seems. Anyways, thanks for the link... it seems to be LEADING to DI, but its not DI. He does something like this: public Gadget() : this(Container.Instance.GetImplementerOf()) { } thats kind of manual DI which is not really DI IMO. Its more Service Locator. EDIT: I also saw part 2 of his blog where he just added XML support to the container. Still not really DI since he is still manually resolving the dependencies which is more Service Locator as I mentioned above. I mean, the pattern is sort of DI with the interfaces in the constructor, but then he uses manual resolution whereas true DI is automatic.

SledgeHammer01

Thanks, I took a look at the code. Its still not very clear how it works. It doesn't seem to use reflection for example to determine parameters. Seems like it uses some other unknown (to me) mechanism.

James McConville

Yeah, I Agree, that example he uses is a bit dodgy but I can understand why he didn't want to write an entire DI engine for a beginners tutorial. Anyway, Like I say, I found it was an ok place to start before moving on to other stuff.