Inversion of Control Proof of Concept (IoC PoC)

View and download the example via Git

The Inversion of Control Proof of Concept solution demonstrates the advantages of a modular, loosely coupled software architecture based on abstraction, inversion of control (IoC), and dependency injection (DI). For more information regarding these concepts, research SOLID software design.

The IocPoc solution contains 3 Web API projects, a Domain project, and 2 Payment Gateways. The domain defines a payment gateway interface that is implemented by the PayPal and AuthorizeDotNet merchant gateways. The solution assumes that the Visual Studio .Net IDE is used to create the projects and demonstrate the solution.


  1. Domain
    1. IocPoc.Domain
      1. Defines payment gateway behavior via an interface (IPaymentGateway) that the payment gateways must implement.
  2. Payment Gateways
    1. IocPoc.PayPal
      1. Implements the domain business object payment gateway interface (IPaymentGateway).
    2. IocPoc.AuthorizeDotNet
      1. Implements the domain business object payment gateway interface (IPaymentGateway).
  3. Web Application Programmable Interfacess (API's):
    1. IocPoc.NoDI
      1. References PayPal and AuthorizeDotNet projects (DLL’s).
        1. AuthorizeDotNet not used.
      2. The controller creates an instance of PayPal and returns a message from the gateway.
    2. IocPoc.DiOne
      1. References IocPoc.Domain.
      2. Uses dependency injection (DI) to inject the PayPal gateway via the controller constructor.
      3. PayPal DLL copied to bin folder, but no reference to it is made in the project.
        1. Unity (DI manager) finds the DLL via web.config mapping to IPaymentGateway and injects it.
    3. IocPoc.DiTwo
      1. Controller method signature exactly the same as IocPoc.DiOne above.
      2. Web.config Unity mapping of AuthorizeDotNet to the IPaymentGateway interface.


All the code is compiled and deployed.


IocPoc.NoDI and IocPoc.DiOne are to use AuthorizeDotNet instead of PayPal. Modifications and redeployment of the API DLLs are not allowed for various business reasons.


  1. IocPoc.DiOne
    1. Because of a tightly coupled architecture, the request cannot be met. In addition, if the code were to be modified, the AuthorizeDotNet gateway class is marked internal and inaccessible to instantiation.
  2. IocPoc.DiTwo
    1. The request can be met due to loose coupling and interchangeable modules.
    2. Copy AuthorizeDotNet DLL to the bin folder.
    3. Modify the Unity config section in web.config to map the AuthorizeDotNet DLL to the IPaymentGateway interface.

In summary, we want to empower you with some basic understanding of high quality software design principles and how they relate to your project. We are more than happy to dive into the details with you regarding the patterns, features, and processes that go into building a successful software product. Contact us to discuss your web application development needs and get answers to any questions you may have.

The WebAppDevCo Team
+1 954 344 4435
Coral Springs, FL 33076