When you have a dependency between two modules, that modules are not well-separated with each other which are not good when design a large application that needs to be modularized and independent. IoC (Inversion of Control or Dependency Injection whatever), as name suggested, comes to rescue us and resolve the problem by injecting an external dependencies to our modules and using the container (that is injected) to decouple the dependencies between modules, so now the dependencies are inverted to our container and that container will control and manage the rest.
Ok, it sounds confusing. Let's me show you some examples..

So our solution from IoC pattern suggestion'd be:

But if we'd like to input some parameter such as connectionString (not only connectionString, also other inputs as you wish!), above figure example cannot solve this problem without create dependency between modules, and if there are chains of those dependencies that could be very bad.

Our hero is IoC container (provider), it can resolve the dependency chain problem by automatically calling the MemberPayment constructor method and support its parameter. We have to just tell them some information about those Concrete class that we want to instantiate without concerning about the dependencies between each module, that's amazing.

One of popular IoC containers is Castle Windsor, http://www.castleproject.org.
The code below demonstrates the use of Castle Windsor library to resolve the problem of Shop and MemberPayment in our previous examples but let's me explain more about my requirements. Since we're building a small shopping service that users come and pay money, we have to know who are our customers so that we can compute special prices for them. In another word, we need to connect with the MembershipProvider database that are far away (assumed).
//all these classes belong to theBlogFor namespace.
interface IPaymentService
{
double CalculateTotalPrice();
}
public class NonMemberPayment: IPaymentService
{
#region IPaymentService Members
public double CalculateTotalPrice()
{
throw new NotImplementedException();
}
#endregion
}
public class MemberPayment: IPaymentService
{
public string ConnectionString;
public MemberPayment(string connectionString){
ConnectionString = connectionString;
}
#region IPaymentService Members
public double CalculateTotalPrice()
{
throw new NotImplementedException();
}
#endregion
}
public class Shop
{
bool isMember = true;
WindsorContainer container;
public void BuyItems(/*...items...*/){
container = new WindsorContainer(new XmlInterpreter(new Castle.Core.Resource.ConfigResource("castle")));
if (isMember)
{
MemberPayment serviceForMember = container.Resolve<IPaymentService>("MemberPayment") as MemberPayment;
System.Windows.Forms.MessageBox.Show(serviceForMember.ConnectionString);
}
else
{
NonMemberPayment serviceForNonMember = container.Resolve<IPaymentService>("NonMemberPayment") as NonMemberPayment;
}
}
}
The point is; container.Resolve<IPaymentService>("MemberPayment"), "MemberPayment" is an ID that you specified in XML config file (see it later). You may have a question how WindsorContainer knows my initial value of the connectionString for MemberPayment. That's because we describe the default parameter of connectionString in config file (that's all). In conclusion, when we call Resolve method, container'll look up the XML (since we tell them to do so by XmlInterpreter(...) ), then it'll know from that config file which components it has to instantiate and give those the parameters they require. After this process, we'll get IPaymentService obj, as expected, and finally the MessageBox'll be shown out with the connectionString message (sound boring..).
Not only you can specify the default connectionString in config file, you can also input the anonymous-type arguments as parameters too : container.Resolve<IPaymentService>("MemberPayment", new { connectionString = "ok! that 's enough, stop this lesson." }).
container = new WindsorContainer(new XmlInterpreter(new Castle.Core.Resource.ConfigResource("castle"))); from this line, we tell WindsorContainer that there is some xml code that it has to concern when building a container as you can see :
<configuration>
<configSections>
<section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler,Castle.Windsor"/>
</configSections>
<castle>
<components>
<component id="NonMemberPayment" service="theBlogFor.IPaymentService,theBlogFor" type="theBlogFor.NonMemberPayment,theBlogFor"/>
<component id="MemberPayment" service="theBlogFor.IPaymentService,theBlogFor" type="theBlogFor.MemberPayment,theBlogFor">
<parameters>
<connectionString>Data Source=MYCOMNAME\SQLEXPRESS;Initial Catalog=theBlogForMembershipProvider;Integrated Security=True;Pooling=False</connectionString>
</parameters>
</component>
</components>
</castle>
</configuration>
We support parameters for MemberPayment since it needs to identify database that keeps members, but for NonMemberPayment, it doesn't care about this at all. You can specify the parameters like above, or specify them inside the property for future use :
<properties>
<connection>YourConnectionString</connection>
</properties>
<component id="xxx" service="yyy" type="zzz">
<parameters>
<connectionString>#{connection}</connectionString>
</parameters>
</component>
Concept of IoC container is very pervasively used in real world app including in MVC that can be combined with ControllerFactory to create sophisticated Controller obj. Examples of MVC can be easily obtained on the Internet. Hope you get something from this article : - )

7a757a31-f19c-448e-b740-0410e330e8d3|2|5.0