Questions about IoC

I am studying about hig开发者_运维知识库h coupling between classes, specifically IoC. I would like to ask some questions:

1. I am using Ninject; which layer should I put the dlls Ninject
2. When I create a setup to send to the client, dlls Ninject also go to the customer?
3. I've been studying the internet and came to the following conclusion: a. Inversion of control is when I changed my classes and I do not instance them within their own class, but passing as parameters or using tools like Ninject b. Dependency injection is when I add to my project interfaces rather than concrete classes.

---

1. The concept of IoC is orthogonal to the concept of architectural layers. You will have to reference Ninject (a) whenever you employ Ninject features such as the [Inject] attribute (typically at the level of the injected classes) or (b) wherever you setup kernels and modules (typically at the client level).

2. Yes. Ninject will become a dependency of your runtime.

3. IoC may present these behaviors, but its core concept might be better understood as the Holywood principle: don't call us, we'll call you. Which means, don't bother setting up your dependencies, because they will be provided for you. You can achieve this by many means, even "by hand", although tools such as Ninject can ease your life tremendously. Anyway, receiving dependency objects by parameter (mostly during object construction) is a very common pattern, as it is defining dependencies by interfaces rather than classes.

Using interfaces might help you to establish contracts, to better separate requirements from implementations (which is the driving reason for applying IoC in the first place). Also, it may help you to write tests and mocks. But that is another universe of possibilities. Have fun! I've been using Ninject for almost a year, and I found it very easy to use and maintain.

---

Ad2. You have to add ninject dlls to your setup.

Ad3. Inversion of control (IoC) has nothing to do with interfaces and classes. You can have highly coupled code with inversion of control.

class GodClass
{
    void DoSth(int param)
    {
        switch (param)
        {
           case 0: Console.WriteLine("param is 0"); break;
           case 1: Console.WriteLine("param is 1"); break;
        }
    }
}

and with IoC it could look like:

class GoodClass
{
     Dictionary<int, BaseClass> _consoleWriters;

     public GoodClass( IEnumerable<BaseClass> writers )
     {
         foreach (var writer in writers) 
            _consoleWriters.Add( writer.ParamSupported, writer);
     }
     void DoSth(int param)
     {
         _consoleWriters[ param ].DoSth();
     }
}

abstract class BaseClass
{
    abstract int ParamSupported {get;}
    abstract void DoSth(int param);
}

class ZeroWriter : BaseClass
{
     override int ParamSupported {get{return 0;}}
     override DoSth(int param) { Console.WriteLine("param is 0"); }
}

class OneWriter : BaseClass
{
     override int ParamSupported {get{return 1;}}
     override DoSth(int param) { Console.WriteLine("param is 1"); }
}

Ad1. I would add IoC framework configuration/initialization in Main function and pass the reference to initialized container to the rest of the code.

---

1. You should have a reference to Ninject anyhwere you use it to register & resolve your dependencies. Most obvious place for this is in your application shell / entry point.
2. Yes

3. On Dependency Injection... Depending on what language you are talking about this might not be true. In C# / VB.NET case, yes. In dynamic language such as JavaScript, Ruby, etc. not really. I guess nowadays, it can also be wrong w/ C# if you are using DynamicObject. By specifying that your class depends on an interface instead of a concrete class, you can easily inject a different implementation of that interface either manually or by using IoC Container like Ninject.

   On Inversion of Control... It is basically saying instead of having a calling class / method creates what other components it needs to do its work, let it be created somewhere else and have it passed to your class / method. Breaking this concrete dependency chain will make your code more loosely coupled and allow you to replace one implementation of the required component with a different component that implemented the same interface / contract.

   An excellent explanation on Dependency Inversion Principle / IOC can be found in http://www.objectmentor.com/resources/articles/dip.pdf.

   Other good resources on this topics:

   • http://www.dotnetrocks.com/default.aspx?showNum=362
   • http://www.dnrtv.com/default.aspx?showNum=126