2

I plan on digging into one of the open source IoC containers to really figure this out 100%, but I figured I would ask the general community also (after not being able to find a direct answer in any of the closely related questions).

As far as I understand the typical IoC implementation, it seems that it is a global class that acts as a singleton with a knowledge of all dependencies. It then uses that knowledge to supply constructor or property parameters where it knows how to fill them in? Maybe I am missing something, thus the question.

Can somebody definitively tell me how IoC works and/or if it is a singleton at its root?

UPDATE

I guess my question would be how do "magic" IoC things work like Ninject.MVC? Where the injection "just works"?

Steven
  • 166,672
  • 24
  • 332
  • 435
Justin Pihony
  • 66,056
  • 18
  • 147
  • 180
  • Ninject.MVC can only work because the MVC framework provides the [DependencyResolver.SetResolver()](http://msdn.microsoft.com/en-us/library/gg401985%28v=vs.98%29.aspx) extension point. If this didn't exist, no IoC container could "just work" with MVC. – default.kramer Nov 05 '12 at 15:49

5 Answers5

1

IoC containers tend not to be singletons, because you may want to have several containers running at the same time (for instance one per layer of your system), although this is not the most common practice.

In order to access your container, you need thus a reference to the actual container itself.

Even if your container is not a true singleton, you may access it as such by using a Service Locator (see also http://msdn.microsoft.com/en-us/library/ff921142(v=pandp.20).aspx).

Roy Dictus
  • 32,551
  • 8
  • 60
  • 76
  • So, you pass the container itself into the controls? When digging into it, that doesn't seem great either. It almost seem to me to be the ServiceLocator pattern? – Justin Pihony Nov 05 '12 at 15:33
  • You can use ServiceLocator in conjunction with an IoC container, like in the examples here: http://blogs.msdn.com/b/miah/archive/2009/05/12/servicelocator-and-unity-be-careful.aspx. – Roy Dictus Nov 05 '12 at 15:36
  • And, no, you don't pass the container around. You configure the container to manage the instantiation of your classes, and then use property injection or constructor injection. You only call the container in specific places. Any good IoC tutorial will teach you how to use it properly. – Roy Dictus Nov 05 '12 at 15:38
  • Are you able to provide a good IoC tutorial? I have used Ninject.MVC, which "just works" and admittedly am using it w/o knowing the underlying implementation (I will def do this now). Now, I am trying to use IoC (Ninject) with WPF and WinForms. So, I am trying to figure out if there is any way to avoid newing the children windows or using something like kernel.Get as it seems to be the locator pattern? I will continue looking for these examples, but it seems that things break down beyond the first level unless you begin passing your locator (kernel) around? – Justin Pihony Nov 05 '12 at 16:13
  • Maybe this is what you need? http://stefanoricciardi.com/2011/01/21/ninject-mini-tutorial-part-1/ Ninject is of course the simplest of the containers, I have more experience with Autofac, Castle Windsor and Unity. For all of these you can find tutorials all over the Web. Good luck! – Roy Dictus Nov 06 '12 at 07:09
  • 1
    -1 Most applications do have one single container, but not a singleton (per pattern definition). Creating a new container everytime would require all mappings to be analyzed and generated each time and it's imho not very effecient way of using a container. Most containers do have the possibility to create a child container and therefore be able to provide custom lifetimes. – jgauffin Nov 06 '12 at 09:36
  • Nobody said you need to create a new container every time. There is no reason to downvote! – Roy Dictus Nov 06 '12 at 10:25
  • @RoyDictus: I tend to agree with JGauffin's down vote. You answer implies that it is quite usuall to have multiple container instances. If this is not what you meant, please update your answer. – Steven Nov 06 '12 at 10:57
  • It doesn't imply that it is usual, it says that it is possible and therefore containers are not defined as singletons. – Roy Dictus Nov 06 '12 at 11:00
  • But the containers do tend to be singleton, not per pattern definition but the way it's used. My interpretation of your answer is that it's more common to use several instances. Feel free to clarify your answer and I'll remove the down vote. – jgauffin Nov 06 '12 at 13:32
1

All major DI frameworks (or at least, within Java and .NET) typically advice to have single container instance during the lifetime of the application. Some containers do support the concept of 'child containers', but those child containers are created from that single container and are in fact just part of that same instance.

It is absolutely possible to have multiple containers, for instance a container per layer or per session, but when you designed your application according to the Dependency Injection principle, you would typically have the best result with one container per application (in the context of .NET this would be per App Domain, or in general, all code that runs in the same memort space). When dealing with an application that consists of a (desktop) client and a web service, both will have their own container (since they are in fact different programs, that have no knowledge of the other).

Although it is possible to define a container instance per (web user) session, request, or something similar, this tends to complicate things a lot, since it is hard to register dependencies with a greater lifetime than the session, and there is a lot of performance overhead in creating a container.

Steven
  • 166,672
  • 24
  • 332
  • 435
0

There's no reason why it should be a singleton. Just because you have your entities plumbed together by a context, you could still run multiple contexts (to use Spring vernacular, but not limiting the argument to Spring)

Note that platforms like Java can't even enforce singletons (due to their multiple classloader architecture).

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
0

OK, after browsing even further online and talking to a co-worker, I believe that there is no way to implement IoC (at least in a stateful program..winforms/wpf) without it being a static singleton. So, I plan on using the Composition Root pattern and use the ninject kernel as a static singleton in a Service Locator way. I will still be calling kernel.Get, but I guess I at least lose the care for the dependencies within that item. I was just running myself in circles :).

Something like this:

Main
{
  setupkernel();
  Application.Run(kernel.Get<Main>);
}

btn_GetChildForm()
{
    kernel.Get<ChildForm>().Show();
}

If somebody knows a better way, then please let me know. Otherwise, this is what I have pieced together as the best way to do this.

Justin Pihony
  • 66,056
  • 18
  • 147
  • 180
  • DI purists recommend avoiding Service Locator (and so do I), but you should never do anything just because someone recommends it :) If you want to avoid Service Locator, you can hide your container behind appropriate abstractions that you create. See [this answer](http://stackoverflow.com/a/8855283/644812) for an example, but it might be more complicated than you need because it involves scoping concerns. (It's for Autofac, but Ninject would be similar.) – default.kramer Nov 05 '12 at 22:32
-1

Service Locator is an Anti-Pattern

Try and understand the nature of the 'Composition Root'.

David Osborne
  • 6,436
  • 1
  • 21
  • 35
  • Yes, this has already been covered in other answers. Your answer does nothing to further the conversation and/or help as even the Composition Root has been discussed...please read other answers before trying a blanket statement with no further details – Justin Pihony Nov 07 '12 at 15:00
  • Are you sure? All I can see is advocacy of service location and a misunderstanding of IoC principles. – David Osborne Nov 07 '12 at 19:00
  • Yes, an advocacy of SL to a certain extent (keep in mind that nothing is black and white and anti-patterns are generally bad, but not always) If you can show me how to accomplish Composition Root in a client app (Winform/WPF) that is not SL, then please update your answer, otherwise, look at my answer for the compromise in this situation. – Justin Pihony Nov 07 '12 at 19:52
  • Mark Seeman has exactly the example you're looking for that correctly implements the concept of a composition root and then resolves dependencies using an abstract factory. I think you can get the source for a wpf sample on the website that accompanies his book. You're example is not really a true composition root as you're subsequently using sl to resolve. All resolution should be done in the composition root or deferred to abstract factories that are resolved in the composition root. – David Osborne Nov 07 '12 at 22:58