Thursday, February 21, 2008

Getting to know IoC (Inversion of Control) Container

sfeldman.NET - Understanding IoC Container (Part 1)

"In a multi layered application architecture, loosely coupled code is more than a important. It's the basic which can either help the entire project progress, or drive it down the slope to the end (in the bad meaning of the word). One of the basics to keep coupling as low as possible is Inversion of Control (IoC) container.

I will try to show how to put in place a simple version of IoC container to allow loosely coupled design. The solution will contain several projects to emulate a layered application as much as possible. The choice of console application is only driven by intent to keep it as simple as possible.


sfeldman.NET - Understanding IoC Container - Part 2

"I try to lower expectations in order not to be disappointed, but in this case I was asked by several individuals to address the fact that IoC container power is in the ability to "hook" implementer with the contract through an external file, leaving application code unaware of the actual implementer till the run-time, having no reference to implementers' assembly or whatsoever. I am going to expand the sample from the part 1 post to achieve that goal in a couple of days.

In the last post we left with the application with an ApplicationStartup() method that would register all implementers against the contracts they implement. That causes a serious coupling between the ConsoleApp assembly and the one that implements the XmlLogger, AssemblyTwo. This is not a good idea, especially when we want to be able to replace the implementer without touching/modifying the application itself (by recompiling it).


I've been hearing and seeing discussions on IoC for a bit now and have been wanting to learn more about it (among the zillion other things I want to learn... Man I LOVE software development! :).

Based on my very limited understanding of IoC Container, it seems that it could help me solve a number of problems (some abstraction and coupling issues I want to address). I've reinvented the wheel a couple times implementing design and runtime abstraction/de-coupling, and I hate that... So I'm thinking/hoping that IoC Container can help me do it "right"...

(via Reflective Perspective - The Morning Brew #37)

No comments: