Eric Nelson was kind enough to invite me to contribute to the MSDN Flash newsletter. It should be published next Wednesday. The article was limited to 500 words, only enough for a very brief introduction to IoC containers, so for those who want to explore this exciting topic further, here are some links:
Oren Eini's (AKA Ayende) MSDN article: Inversion of Control and Dependency Injection: Working with Windsor Container:
http://msdn.microsoft.com/en-us/library/aa973811.aspx
Hamilton Verissimo's Code Project article: Introducing Castle - Part 1:
http://www.codeproject.com/KB/architecture/introducingcastle.aspx
The first chapter of Dhanji R. Prasanna's new book on Dependency Injection:
http://www.manning.com/prasanna/prasanna_meapch1.pdf
Some popular IoC containers for .NET:
Castle Windsor. This one is probably the most popular, I'm biased though since it's the one I use. It was originally written by Hamilton Verissimo (who now works on the MEF team) and maintained is by Ayende.
StructureMap. Also very highly regarded. It's author, Jeremy Miller, has an excellent blog.
Spring.NET. A port of the popular Java Spring container.
Ninject and Autofac are both interesting newcomers.
Unity is from the Microsoft Patterns and Practices group.
Glen Block will kill me, but MEF is also an IoC container, although one that's specifically targeted at developing plug-in application architectures.
Posts
10 comments:
Will you cover some of the pitfalls - such as Windsor doesn't do well with cleaning up resources on instance objects - that it's primarily for static objects?
Hi Anonymous
By 'static' I guess you mean the singleton lifestyle, and by 'instance' you mean transient?
I haven't noticed any problems with un-released objects in my projects and I primarily build web application and mark my components as transient. On the whole Windsor is pretty good at releasing references. Can you give a specific example of where you've had problems?
Hi Mike!
A very long time nospeak/hear/see. It's Ian Pender here - it's been a few years. Stumbled across your blog a while ago and I have a little look now and again - very nice!
Now I've been using IoC for a couple of years now and all is fantastic, but I've hit a problem and found little support on Castle's site. I just wondered if you had the answer .... if that's not too cheeky.
We're using Windsor, and have different IoC containers for different environments. Now ideally we'd like to inherit these IoC settings down, but we can't see a way to re-register a service within a container (to be clear we want to update the service against an interface in a container).
Any idea at all ? We've looked at AddComponent overloads. We really want to use code to register rather than config....
Hello again, btw ! Hope you and the family are well!
How do you usually pass a reference to the container itself? Do you use a static property?
Hi Ian,
Great to hear from you. Can you email me (mikehadlow at yahoo dot com) and I'll try to help.
Ulu,
I'm not sure what you mean. Can you be a little more specific about what you'd like to do? A reference to what? To be used where?
Thanks
For example, in a Web application an instance of the container should be created somewhere, and passed somehow to other parts of the application.
Hi Ulu,
The answer is that you shouldn't have references to the container scattered around your application. You should create and configure the container at application start, resolve the root object of your application's object graph and then rely on the container to create instances of dependent objects.
Have a look at the Suteki Shop code especially Global.asax.cs InitializeWindsor()
http://code.google.com/p/sutekishop/source/browse/trunk/Suteki.Shop/Suteki.Shop/Global.asax.cs
If you *must* get an object directly from the container use the Common Service Locator:
http://www.codeplex.com/CommonServiceLocator
I see. You are referring to an MVC Asp.Net application. With WebForms, it's got to be a ServiceLocator, I guess..
Hi Ulu,
WebForms is a poor choice for component oriented application development. You are faced with building your own abstraction (MVC/MVP) on top of it if you are serious about components. I would recommend that you seriously consider using MVC Framework or Monorail instead.
Post a Comment