C.Inversion of control (IOC)

  1. Inversion (Defined)

      1. Inversion means reverse approach from common pratices and in terms of software it relates to reversing the dependency flow.

  2. The IOC

      1. IOC is technically a Design Guidelines or Principle that tells how to apply or implement Dependency Inversion Principle during development.

      2. It guide that object that consumes the dependencies (like Object) must not be creating the object , someone else should be doing that job.

    1. It further suggest that as much as possible assemble your dependencies (like child object) at run time that gives highest level of decoupling.

  1. Type of Inversion

    1. Interface Inversion : It tells that concumer of object or service should suggest the provides , what interface to implement.

      1. It further suggest that "You should create and implement interface only when if there is more that one implementation" in other words consumer should not implement provider interfaces but provider should implement a common interface suggested by customer.

      2. Flow Inversions : Suggest to write program logic in call back approach for ex console application vs GUI based application that are event driven.

      3. Creation Inversion: This is most common type of inversion seen in software development industry. Other synonyms are Binding Inversion,Dependency Inversion and it is generally achieve through some sort of dependency injection mechanism.

    1. Types of Creation Inversion

      1. Factory Pattern

      2. Service Locator

      3. Dependency Injection : Mostly implemented by some short of IOC containers , that internally might use factory as well.

        1. Type of Dependency Injections

          1. Constructor Injection : Most common type of DI

          2. Setter Injection : Second most common type of ID.

          3. Interface Injection:

            1. Dependent calss implent an interface that consumes an other interface.

            2. It is an alternative to setter injection.

          4. Using this pattern dependet class declare that it can be injected

    1. IOC Containers

        1. IOC Containers are frameworks that provide an easy way to dynamically create and inject dependencies in system (DI) while from outside of the system.

        2. IOC Container are alternative to Factories and highly flexible when compared with factories.

        3. Conceptually containers are generalized factories.

  1. Comparison of Popular IOC Containers.

      1. Unity (Microsoft) : Nice choice , some OK type restriction , but well documented and well supported.

    1. Castle Windsor : Vary stable and bit more powerful than Unity.

      1. StructureMap : Very powerful and flexible but bit high learning curve

      2. Ninject. :It tops in performance rating.

      3. Spring.NET Flexible, powerful but complex to learn and configure.

  1. Specific Considerations

    1. IOC Vs Hollywood Principle

      1. Inversion of control is sometimes facetiously referred to as the "Hollywood Principle: Don't call us, we'll call you", because program logic runs against abstractions such as callbacks.

    2. IOC Containers and DI Containers are just synonyms

    3. Containers Vs Factories

        1. Containers are generalized factories and should be preferred over Factories when factory configuration need to be modified at run time. http://msdn.microsoft.com/en-us/magazine/cc163739.aspx

        2. In large application with lot of object factories could be good choice.

    4. Container Downsides

        1. They violate encapsulation principle and exposes object construction logic out side the consumer class.

        2. Add more debugging and learning complexities.

      1. Service Locator Vs Container

        1. In case of Service Locator we need to tell what to create i.e. name of the concrete class then it know how to create.

        2. In case of container all we need to tell the container what to resolve , what to create and how to create is taken care by containers itself based on some configuration and run time logic implemented inside.

  1. When to use IOC/Containers.

      1. IOC should not be used without a good reason because it adds complexity to the program.

    1. Consider using IOC only when you need to changes components at run time such as choosing a ticket booking partner based on business profit calculations

  1. References