How to Write your own Dependency Injection Engine!

[UPDATE] Just added all the code to this posting as well, so you can follow along without having to download files!

Init()
The init() method is fairly simple. It just needs to set all of the properties in the variables scope and then if lazy loading is off, it needs to loop through all of the singletons and if they don’t already exist in the variables scope in LightWire, it should create them. How would they already exist? Well, because each singleton may be dependent on other singletons. Every getObject() call creates not only the requested object, but any of its dependencies, so even when initializing LightWire, it is quite likely that by the time you get to some of the later singletons, they will already exist.

The Configuration File
I tend to prefer programmatic config files for a number of reasons (it is well worth reading both that section and the whole article). That said, I understand the benefits of XML configuration files as well. For now I’ve decided just to provide support for a programmatic configuration file and I’ll add a simple translator for reading an XML file or object when someone asks for one (I’ll base the XML off of the Java Spring DTD).

The programmatic configuration file is very simple indeed with the following system settings:

Lazy load - If this is set to 1, LightWire will just load components and their dependent components as required. If 0, LightWire will load all of the singletons in a project on first being called. Lazy loading speeds up first page load for complex applications – especially when testing. Recommended setting: 1 (lazy load on). Please note that lazy loading is only available at a system level – not a bean level.
e.g. variables.LightWire.LazyLoad = 1
Base class path - The base class path allows you to more easily reuse configurations between applications. Instead of having to change the class path for every single bean, you can just change the base class path in one place (and you can even set it using a variable if the base class pass is always #application.name#.com or something similar – one of the benfits of programmatic config files).
e.g. variables.LightWire.BaseClassPath = "myapp.com";

Then for every bean in the application, you need to create a structure under variables.Bean with the following required and (if wanted) optional properties:
Required
Singleton - Whether the bean is a singleton or a transient. 1 = singleton.
e.g. variables.Bean.UserService.Singleton = 1;
Path - The path to the bean relative to the base class path. Can be blank if it is in the base class path directory.
e.g. variables.Bean.UserService.Path = "model.user";

Optional
Constructor dependencies - An optional comma delimited list of the names of any beans that need to be passed to the init() method of the bean.
e.g. variables.UserService.ConstructorDependencies = "UserDAO,UserGateway";
Setter dependencies - An optional comma delimited list of any bean names that need to be injected using setter injection. e.g. variables.testService.SetterDependencies = "CompanyService";
Mixin dependencies - An optional comma delimited list of any bean names that need to be injected using mixin injection.
e.g. variables.UserService.MixinDependencies = "ProductService";
Constructor Properties - An optional struct containing any non-bean constructor properties required by the init() method. Can contain any simple or complex data types within the struct which is passed into the init() method using ArgumentCollection after having any constructor dependencies (beans) added automatically.
e.g. variables.UserService.ConstructorProperties.PropertyName = "This Value";

Sample config file:

Creating Objects
Whether you are lazy loading or not, getObject() is the private method that does all of the heavy lifting. It is called by the init() method (if you are not lazy loading) and by LightWire’s two other public methods: getSingleton() and getTransient(). Each takes the name of an object and calls getObject(ObjectName,”Singleton”) or getObject(ObjectName,”Transient”) respectively. Both return a fully loaded object with all of its dependencies resolved and injected (constructor, setter and mixin).

getDependentObjectList()
The first thing getObject() does is to get a list of all of the dependent constructor objects n-levels down by calling getDependentObjectList(). getDependentObjectList() just takes the name of an object (singleton or transient) and looks to see if it has any constructor dependencies, recursively. So, if you passed in “UserService“, it might return UserDAO, DataSource which means that UserService requires UserDAO and that in turn required Datasource.

Basically, getDependentObjectList() just gets a list of all of the dependencies for the requested object that don’t already exist (if they’re already created, they don’t need to be re-created). It then gets a list of all of the dependencies for any dependent objects recursively until there are no dependencies left.

Please note that sometimes a dependency might come up more than once. For instance, if UserService depends on UserDAO and UserGateway and both depend on DataSource, then assuming none of them have yet been created, getDependentObjectList() would naively return UserDAO, DataSource, UserGateway, DataSource. I have added a while loop to remove any existing references, so the function will actually return UserDAO, UserGateway, DataSource. It is important that it is only the last instance that is left as we will be constructing from last to first, so if both DAO and Gateway need DataSource, it must be constructed before either of them.

Circular Dependencies
getDependentObjectList() needs to test for circular dependencies. In the case of constructor dependencies, it needs to fail if there are any circular dependencies and in the case of setter dependencies, it just needs to be smart enough not to get into an infinite loop.

The only way to find circular dependencies is to keep track of the dependency path for each object and to make sure that you don’t add a dependent object that is on its own parent path. So, if ProductService is dependent on ProductDAO which is dependent on DataSource, it is NOT OK for DataSource to depend on ProductService or ProductDAO. I’m doing this by adding pipe delimited list of dependency sets to the ObjectDependencyList. I don’t love this approach, but it keeps the code fairly simple and will catch any circular dependencies and seems to be working well and catching all of the test cases I can think of.

Creating Objects
The next step is to create all of the objects required, starting at the right hand most end of the list and working back. Each object needs to be created and constructed (by calling init()) before the previous object can be called. All of the creation (including pulling together any constructor properties and objects) is handled by createNewObject() which is called once for each dependent object and then finally once for the object originally requested.

Setter and Mixin Injection
Before the objects can be returned, they need to have any non-constructor injections taken care of. As well as the standard setter injection (based on set%ObjectName%() methods), I have also added a mixin injection option. The difference between setter and mixin injections is that setter injection requires a set%objectName%() method whereas mixin injection doesn’t. If you need to do anything more than just pass the dependent object in, you want to use setter injection so the setter method can handle any custom logic. If not, you can just use mixin injection to avoid having to mess up your objects API with setter methods that are really only for pseudo-construction purposes.

Handling Circular Setter and Mixin Dependencies
This is something I actually don't need to track. Because of the way my setter and mixin dependency injections work, they don't get stuck in a loop with circular dependencies, they just work!

Conclusion
So, plenty of testing required, but I feel I've learnt a lot writing LightWire, it only took a few hours and it still weighs in at under 300 lines of code in a single cfc. It also provides a programmatic config file, mixin injections, base class paths and a few other little enhancements that work really well for the way I program. Hey, it's not ColdSpring, but it is still kinda fun!