Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Let's keep all the IoC frameworks aside and discuss the concept. IoC is not a new concept and has been around for a long time. IoC is basically implemented to make your system loosly coupled to certain subsystem. We achieve decoupling by extracting out common/core behavior of subsystem into a contract. Contract is usually in shape of interface. Now you depend on this interface. You are not worried about how a particular system concretely gives you the behavior that you are after. </p> <p>Recently I had real life encounter with this. We are having one existing payment system and then we are developing a new payment system to adhere to PCI. What you do in these kind of situation is that you extract the common features of both systems in an interface and then your application interacts with these two systems only via interface. You can either use a flag in config file or factory pattern or ultimately an IoC framework to inject this dependency in your application. At runtime your application will get the object that it depends on. You need DI/IoC in an environment where uncertainty is there regarding the use of any given subsystem due to any reason. In this example new payment system couldn't get delivered on time and hence my application needed a configurable option to switch between any system at runtime. If I don't do IoC, I will have to do code change every time business changes their mind.</p> <p>Another need of IoC is to do TDD. Same thing that I described above can be used to develop a mock implementation of real application and can be used to do testing while real component is still in development.</p> <p><a href="http://www.manning.com/prasanna/" rel="noreferrer">Dependency Injection</a> is a good book to start with. You can also download a free paper on DI from the same author <a href="http://www.manning.com/free/green_prasanna.html" rel="noreferrer">here</a>. </p> <p>Update: Adding code for more clarity</p> <pre><code>public interface ITest { void Hello(); } </code></pre> <p>Now I can have two different concrete implementations:</p> <pre><code>public class Hi : ITest { public void Hello() { HttpContext.Current.Response.Write("Hi there!"); } } public class HelloMessage : ITest { public void Hello() { HttpContext.Current.Response.Write("Hello there!"); } } ITest messenger; if (User Needs "Hi") { messenger = new Hi(); } else if (User Needs "Hello") { messenger = new HelloMessage(); } messenger.Hello(); </code></pre> <p>All my application has to do is call the method available in contract. Right now application is handling the dependencies explicitly but is free of any concrete implementation. However it is still tied to these two concrete implementations. IoC frameworks helps us to outsource this job to a configuration file. There I can provide any other concrete implementation regardless of how it is implemented and application will continue to work without any code change.</p> <p>Following is the code where I am using Unity 2 and outsourcing explicit handling of dependencies on my own.</p> <pre><code>using (IUnityContainer container = new UnityContainer()) { container.LoadConfiguration(); ITest messenger = container.Resolve&lt;ITest&gt;(); messenger.Hello(); } </code></pre> <p>Config for the same:</p> <pre><code>&lt;unity xmlns="http://schemas.microsoft.com/practices/2010/unity"&gt; &lt;assembly name="Injection"/&gt; &lt;container&gt; &lt;register type="Injection.ITest" mapTo="Injection.Hi"/&gt; &lt;/container&gt; &lt;/unity&gt; </code></pre> <p>HTH</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload