Actually this is not Yet Another DI Article (YADIA - see anyone can create an acronym!).
This question has been asked many times in many places, the most recent one I've noticed being a question on LinkedIn. My first reaction, like everyone else was to try and explain DI. But then I thought, why not take a new approach?
So here I'm going to try and explain DI, not by talking about it, but by talking about ...
What it can do for you
The one biggest gain from using a good DI framework (yep, shameless self promotion there!) is to reduce and simplify your code. When you introduce a framework you should be able to remove all this code:
- Singleton creation code. Singletons are a pain in the rear and really should be avoided. Unfortunately, iOS developers have a tendency to be heavy handed with them. A DI framework should allow you to remove all the code that defines and creates them.
- Code which passes instances around without actually using them. Think of the times you've passed something to a view controller just so it can pass it to something else.
- Injection code. i.e. any code that locates some object and passes/injects it into another. The framework should help with this by letting you define where you require something and how to find the value to set. The actual instantiating and locating of the value, then setting it should be handled by the framework.
- Messy configuration code. By this I mean that the framework should assist you when configuring for different situations. For example, it could inject a dummy network service object instead of a live one for demo purposes. Your code wouldn't contain anything that did the switching. The framework would handle it automatically. Messy test code. Especially where you are attempting to override instances of objects with test oriented one. The framework should be able to assist in this by allowing you to define test instances that replace the originals.
So essentially, if you bring a DI framework into your project and you don't find yourself removing code, or even worse - you find yourself adding code (You know who you are!). Then you need to look for a different framework.
Reality is that any framework you use should help you simply what you are doing.
But is that all they can do?
Hopefully not. In Java land the Spring framework does an enormous amount of other things. Database management, transactions, back ground tasks, web page formatting, Aspect orientated cross cuts, JSON and XML formatting, and the list goes on and one.
Thats simply because Spring has been around a long time an people have contributed a huge amount of functionality to it beyond simple DI. iOS DI frameworks on the other hand are still pretty new and rarely have much more than DI functionality.
With Alchemic, I'm endeavouring to start thinking about what it can do beyond DI. And to look at creating a suite of functionality to match. Already I've built in functionality to automatically setup your
UIApplicationDelegate instance on startup so that it can be injected like any other object. But I also intend to create a standard suite of objects for handling application properties, specific unit testing functionality and localised message injections. From there the sky the limit. I'm thinking enhanced MVVM support for example.