ansaurus

Question

IoC and ASP.NET MVC, where does it all begin?

Answer 1

+1 A:

For some video intros, check out DimeCasts.net.

The main two reasons I like Ioc:

Easier Unit Testing.
Easier to swap out backend data to test. Say you have a IPersonRepository. Your code implements a PersonRepository that loads data from the database. But what if you don't have any data in the database or the database isn't set up yet? You use IoC to implement a DummyPersonRepository that will load the data from somewhere else, like an XML file, or hardcoded data.

Martin 2010-10-21 13:06:44

actually the dime casts are quite outdated so while they do show some good stuff, they also show some practices and code that is discouraged now.

Krzysztof Koźmic 2010-10-21 13:25:34

Answer 2

+3 A:

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.

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.

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.

Dependency Injection is a good book to start with. You can also download a free paper on DI from the same author here.

Update: Adding code for more clarity

public interface ITest
    {
        void Hello();
    }

Now I can have two different concrete implementations:

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 Hi();
}

messenger.Hello();

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.

Following is the code where I am using Unity 2 and outsourcing explicit handling of dependencies on my own.

using (IUnityContainer container = new UnityContainer())
            {
                container.LoadConfiguration();

                ITest messenger = container.Resolve<ITest>();

                messenger.Hello();
            }

Config for the same:

<unity xmlns="http://schemas.microsoft.com/practices/2010/unity"&gt;
  <assembly name="Injection"/>
  <container>
    <register type="Injection.ITest" mapTo="Injection.Hi"/>
  </container>
</unity>

HTH

Pradeep 2010-10-21 13:23:11

I am unfamiliar with some of your acronyms. "PCI" and "TDD" and what they mean in relationship to this discussion. Can you clarify?

Stacey 2010-10-21 13:38:32

The green paper that you can download doesn't seem to have a file format, and I cannot get it to open in anything in particular. What should I use to read this file?

Stacey 2010-10-21 13:42:56

TDD stands for Test Driven Development. PCI DSS is Payment Card Industry Data Security Standard and that was my specific scenario. Green paper is in PDF version and you should not have any problem opening it if you have any PDF reader.

Pradeep 2010-10-21 14:13:56

Thanks, this gives a lot of very good information.

Stacey 2010-10-22 15:27:06

Answer 3

A:

I asked something similar a while ago, some nice answers over there at http://stackoverflow.com/questions/770039/examples-of-ioc-containers

Morph 2010-10-21 13:46:07

ansaurus

tags:

views:

answers:

IoC and ASP.NET MVC, where does it all begin?

related questions