RESTful Day 2: Inversion of Control Using Dependency Injection in Web API's Using Unity Container and Bootstrapper

/// <summary>
/// Public constructor to initialize product service instance
/// </summary>
public ProductController()
{
    _productServices = new ProductServices();
}

/// <summary>
/// Public constructor.
/// </summary>
public ProductServices()
{
    _unitOfWork = new UnitOfWork();
}

using System.Web.Http;
using System.Web.Mvc;
using BusinessServices;
using DataModel.UnitOfWork;
using Microsoft.Practices.Unity;
using Unity.Mvc3;

namespace WebApi
{
    public static class Bootstrapper
    {
        public static void Initialise()
        {
            var container = BuildUnityContainer();
            DependencyResolver.SetResolver(new UnityDependencyResolver(container));
            // register dependency resolver for WebAPI RC
            GlobalConfiguration.Configuration.DependencyResolver = new Unity.WebApi.UnityDependencyResolver(container);
        }
        private static IUnityContainer BuildUnityContainer()
        {
            var container = new UnityContainer();

            // register all your components with the container here
            // it is NOT necessary to register your controllers

            // e.g. container.RegisterType<ITestService, TestService>();
            container.RegisterType<IProductServices, ProductServices>().RegisterType<UnitOfWork>(new HierarchicalLifetimeManager());

            return container;
        }
    }
}

// register all your components with the container here
// it is NOT necessary to register your controllers

// e.g. container.RegisterType<ITestService, TestService>();

container.RegisterType<IProductServices, ProductServices>()
    .RegisterType<UnitOfWork>(new HierarchicalLifetimeManager());

public static class Bootstrapper
{
    public static void Initialise()
    {
        var container = BuildUnityContainer();

        DependencyResolver.SetResolver(new UnityDependencyResolver(container));

        // register dependency resolver for WebAPI RC
        GlobalConfiguration.Configuration.DependencyResolver = new Unity.WebApi.UnityDependencyResolver(container);
    }

    private static IUnityContainer BuildUnityContainer()
    {
        var container = new UnityContainer();

        // register all your components with the container here
        // it is NOT necessary to register your controllers

        // e.g. container.RegisterType<ITestService, TestService>(); 
        container.RegisterType<IProductServices, ProductServices>().RegisterType<UnitOfWork>(new HierarchicalLifetimeManager());

        return container;
    }
}

That, we can also specify other dependent objects in BuildUnityContainerMethod.

Step 4. Now we need to call the Initialise method of the Bootstrapper class. Note, we need the objects as soon as our modules load, therefore we require the container to do its work when the application loads, therefore go to the Global.asax file and add one line to call the Initialise method. Since this is a static method, we can directly call it using the class name as in the following.

Bootstrapper.Initialise();

Our global. asax becomes.

using System.Linq;
using System.Web.Http;
using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
using Newtonsoft.Json;
using WebApi.App_Start;

namespace WebApi
{
    // Note: For instructions on enabling IIS6 or IIS7 classic mode,
    // visit http://go.microsoft.com/?LinkId=9394801

    public class WebApiApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();

            WebApiConfig.Register(GlobalConfiguration.Configuration);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
            
            // Initialise Bootstrapper
            Bootstrapper.Initialise();
            
            // Define Formatters
            var formatters = GlobalConfiguration.Configuration.Formatters;
            var jsonFormatter = formatters.JsonFormatter;
            var settings = jsonFormatter.SerializerSettings;
            settings.Formatting = Formatting.Indented;
            // settings.ContractResolver = new CamelCasePropertyNamesContractResolver();
            var appXmlType = formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");
            formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);

            // Add CORS Handler
            GlobalConfiguration.Configuration.MessageHandlers.Add(new CorsHandler());
        }
    }
}

Half of the job is done. We now need to touch base with our controller and service class constructors to utilize the instances already created for them at application load.

Setup Controller

We have already set up Unity in our application. There are various methods in which we can inject a dependency, like constructor injection, and property injection, via a service locator. I am here using Constructor Injection because I find it the best method to use with Unity Container to resolve dependency.

Just go to your ProductController, and you find your constructor written as.

/// <summary>
/// Public constructor to initialize product service instance
/// </summary>
public ProductController()
{
    _productServices = new ProductServices();
}

Just add a parameter to your constructor that takes your ProductServices reference, as we did in the following.

/// <summary>  
/// Public constructor to initialize product service instance  
/// </summary>  
public ProductController(IProductServices productServices)  
{  
    _productServices = productServices;  
}  

And initialize your “productServices” variable with the parameter. In this case, when the constructor of the controller is called, it will be served with a pre-instantiated service instance and does not need to create an instance of the service, our Unity container did the job of object creation.

Setup Services

For services too, we proceed in a similar fashion. Just open your ProductServices class, we see the dependency of UnitOfWork here as in the following.

/// <summary>
/// Public constructor.
/// </summary>
public ProductServices()
{
    _unitOfWork = new UnitOfWork();
}

Again, we perform the same steps and a parameter of type UnitOfWork to our constructor.

Our code becomes

/// <summary>
/// Public constructor.
/// </summary>
public ProductServices(UnitOfWork unitOfWork)
{
    _unitOfWork = unitOfWork;
}  

Here we'll also get the pre-instantiated object on UnitOfWork. So the service does not need to worry about creating objects. Remember, we did .RegisterType<UnitOfWork>() in the Bootstrapper class.

We have now made our components independent.

Image source: http://4.bp.blogspot.com/-q-o5SXbf3jw/T0ZUv0vDafI/AAAAAAAAAY4/_O8PgPNXIKQ/s320/h1.jpg

Running the application

Our job is nearly done. We need to run the application. Just hit F5. To our surprise, we'll end up with in an error page as in the following.

Do you remember? We added a test client to our project to test our API in my first article. That test client has a controller too, we need to override its settings to make our application work. Just go to Areas -> HelpPage -> Controllers -> HelpController in the WebAPI project as in the following:

Comment out the existing constructors and add a Configuration property like shown below.

// Remove constructors and existing Configuration property.
   
// public HelpController()
//     : this(GlobalConfiguration.Configuration)
// {
// }

// public HelpController(HttpConfiguration config)
// {
//     Configuration = config;
// }

// public HttpConfiguration Configuration { get; private set; }

/// <summary>
/// Add new Configuration Property
/// </summary>
protected static HttpConfiguration Configuration
{
    get { return GlobalConfiguration.Configuration; }
}

Our controller code becomes.

using System;
using System.Web.Http;
using System.Web.Mvc;
using WebApi.Areas.HelpPage.Models;

namespace WebApi.Areas.HelpPage.Controllers
{
    /// <summary>
    /// The controller that will handle requests for the help page.
    /// </summary>
    public class HelpController : Controller
    {
        // Remove constructors and existing Configuration property.

        // public HelpController()
        //     : this(GlobalConfiguration.Configuration)
        // {
        // }

        // public HelpController(HttpConfiguration config)
        // {
        //     Configuration = config;
        // }

        // public HttpConfiguration Configuration { get; private set; }

        /// <summary>
        /// Add new Configuration Property
        /// </summary>
        protected static HttpConfiguration Configuration
        {
            get { return GlobalConfiguration.Configuration; }
        }

        public ActionResult Index()
        {
            return View(Configuration.Services.GetApiExplorer().ApiDescriptions);
        }

        public ActionResult Api(string apiId)
        {
            if (!String.IsNullOrEmpty(apiId))
            {
                HelpPageApiModel apiModel = Configuration.GetHelpPageApiModel(apiId);
                if (apiModel != null)
                {
                    return View(apiModel);
                }
            }

            return View("Error");
        }
    }
}

Just run the application, we get.

We already have our test client added, but for new readers, I am just again explaining how to add a test client to our API project.

Just go to Manage Nuget Packages by right-clicking the WebAPI project and type WebAPITestClient into the searchbox in online packages as in the following.

You'll get “A simple Test Client for ASP.NET Web API”, just add it. You'll get a help controller in Areas -> HelpPage as shown below.

I have already provided the database scripts and data in my previous article, you can use that.

Append “/help” in the application URL and you'll get the test client as in the following.

You can test each service by clicking on it.

Service for GetAllProduct.

To create a new product.

In the database, we get a new product as in the following.

Update product.

We get the following in the database.

Delete product.

In the database.

Job done.

Image source http://codeopinion.com/wp-content/uploads/2015/02/injection.jpg

Design Flaws

What if I say there are still flaws in this design, the design is still not loosely coupled?

Do you remember what we decided when writing our first application?

Our API talks to services and services talk to the DataModel. We'll never allow the DataModel to talk to the APIs for security reasons. But did you notice that when we were registering the type in the Bootstrapper class, we also registered the type of UnitOfWork? That means we added the DataModel as a reference to our API project. This is a design problem. We tried to resolve the dependency of a dependency by violating our design and compromising security.

In my next article, we'll overcome this situation, we'll try to resolve the dependency and its dependency without violating our design and compromising security. In fact, we'll make it more secure and loosely coupled.

In my next article, we'll make use of the Managed Extensibility Framework (MEF) to do that.

Conclusion

We now know how to use Unity container to resolve a dependency and perform Inversion of Control.

But still, there are some flaws in this design. In my next article, I'll try to make the system stronger. Until then Happy Coding. You can also download the source code from GitHub. Add the required packages, if they are missing in the source code.

Read more

• C# and ASP.NET Questions (All in one)
• MVC Interview Questions
• C# and ASP.NET Interview Questions and Answers
• Web Services and Windows Services Interview Questions

For more technical articles you can reach out to CodeTeddy

My other series of articles.

• Learning MVC
• Learning OOP concepts with C#