Dependency injection and Inversion of Control (IOC)

I was involved in an interesting debate a few days ago regarding the importance of IOC containers and whether they are necessary, whilst this post will not teach you what IOC is (there are many excellent posts that do this) I just wanted to share my experience with IOC and one of the most compelling reasons for using them.

Sure, you can get by without using them, they are not mandatory for Dependency Injecion, however if you follow the Single Responsibility Principle (SRP), you will find they are a huge as advantage and also clean up your code no end.

For me, the “Eureka!” Moment came whilst doing TDD for the first time whilst exercising Separation Of Concerns and the Single Responsibility principle, I noticed that my class construction was becoming too involved and almost unreadable.

To quickly demonstrate this, I’ve put together a very crude implementation to demonstrate how IOC can assist.

For example, if I had a UserRegistration component that is dependent on a number of other classes, this is how it might look:


IUserRegistration registration = new UserRegistration(new CRMUserRegistration(),
new UserEmailSender(new SMTPService()),
new MembershipEmailSender(new SMTPService()));

As you can see, there are several dependencies being injected here. With a tool like StructureMap, all you need is a single declaration


IUserRegistration userRegistration = ObjectFactory.GetInstance<IUserRegistration>();

 

This does require a little setup:


var container = new Container();
container.Configure(x =>
{
x.For<ICRMUserRegistration>().Use<CRMUserRegistration>();
x.For<IMembershipEmailSender>().Use<MembershipEmailSender>();
x.For<ISMTPService>().Use<SMTPService>();
x.For<IUserEmailSender>().Use<UserEmailSender>();
x.For<IUserRegistration>().Use<UserRegistration>();
});

This only needs to be done once in your code (normally on application start up)

As a user of the component you no longer need to know (or even care) what all the dependencies are which is great 🙂 You can still use the older method of declaring dependencies however there really is no need. StructureMap will automatically new up and instances that are required and even walk through the dependency tree creating any new instances that are necessary in any sub components that are required.

Also, as you are using an IOC (in the case StructureMap), you can quickly make an instance a Singleton instance without modifying your class:


x.For<ICRMUserRegistration>().Singleton().Use<CRMUserRegistration>();

I’ve quickly put together a project that demonstrates this principle .. not that none of the code does anything, this is purely for demonstration purposes 🙂

https://github.com/jamielittle/IOCDemonstration

Within the project there is a RegistrationController.cs class which demonstrates the above – bear in mind the project doesn’t do anything, it’s purely for educational purposes. If I get a bit of time I might turn it in to something more useful 🙂

So, to conclude, there is no longer any need to create your own class factories to do this. IOC Containers are the way to go (well, in my opinion anyway).

Many many awesome posts have been written on this subject, take a look below for some further reading:

http://cardinalcore.co.uk/category/testing/

https://kevinobee.wordpress.com/2013/11/12/dependency-injection-with-sitecore/

Advertisements

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