Software Programming

Kunuk Nykjaer

Use the DI container as a way to monitor and maintain the health of the architecture

leave a comment »


Imagine your have been given the task as a technical architect for a large project.

Are you going to use a DI container?
If not you should consider using a DI container.

DI containers makes your architecture more manageable.
Not only manageable for the implementation details but it also enables you to control how your developers will implement and use the services in the project.

Imagine you you have N developers and they are giving various tasks to implement.
How do you manage, monitor, handle changes and orchestrate their usages and implementation of the various architectural services such as:
caching, repositories, CMS-services, feed-services, logging?

How do you make sure the developers don’t make duplicated implementations and how do the developers know where to find the existing implementations used across the architectural layer?

What you can do is to let the developers express their need and let a framework (e.g. DI container) provide the services they need.

Taken from How to explain dependency injection to a 5-year old?

“When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.

What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.”

Here the developers are the 5-year olds – metaphorically 🙂
They might break things and do stuff not approved by the architect.
What the architect should do is to provide the services which the developers need.

I am using MVC Asp.Net as an example (MVC based web-site)
You are building a news website.

Imagine you have a NewsController with the action Politics and a SportController with the action Tennis.

The developer needs to read data from a CMS system and return a view with populated model.
The developer has a need (read data from CMS system).

Example 1 – using DI

    public class NewsController : Controller
    {
        private readonly ICmsService _cmsService;
        public NewsController(ICmsService cmsService)
        {
            _cmsService = cmsService;
        }
		
		public ActionResult Politics()
        {
            var viewModel = new ViewModel { Data = _cmsService.GetData("politics") 
            return View(viewModel);
        }
	}
	
    public class SportController : Controller
    {
        private readonly ICmsService _cmsService;
        public SportController(ICmsService cmsService)
        {
            _cmsService = cmsService;
        }
        public ActionResult Tennis()
        {
            var viewModel = new ViewModel { Data = _cmsService.GetData("tennis") };
            return View(viewModel);
        }
    }

The developers simply add the needed service in the constructor and the service will be provided.
The developers don’t have to update the code if the service implementation is changed.
The developers must use the correct interface and the object instance is provided from elsewhere, i.e. injected.

Imagine the alternative version

Example 2 – not using DI

    public class NewsController : ServiceController
    {
        private readonly ICmsServiceImplementedByDeveloper1 _cmsService;
        public NewsController()
        {
            _cmsService = new CmsServiceImplementedByDeveloper1();
        }

        public ActionResult Politics()
        {
            var viewModel = new ViewModel { Data = _cmsService.GetData("politics") };
            return View(viewModel);
        }


    public class SportController : Controller
    {
        private readonly ICmsServiceImplementedByDeveloper2 _cmsService;
        public SportController()
        {
            _cmsService = new CmsServiceImplementedByDeveloper2();   
        }
        public ActionResult Tennis()
        {
            var viewModel = new ViewModel { Data = _cmsService.GetData("tennis") };
            return View(viewModel);
        }
    }

Here the developers have implemented their own interfaces because it was not provided and they made their own implementation to read from the CMS due to lack of communication or because they needed an implementation which was not provided at the time. Here we see code duplication. And worse when there are changes for the CMS service then all the developers must update their implementation of the CMS service. This makes it harder to maintain and adjust the system.

Advertisements

Written by kunuk Nykjaer

March 11, 2014 at 12:01 am

Posted in Csharp

Tagged with , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: