Nate's Programming Blog

Well this week and last I wrote a light-weight dependency injection framework based on spring’s context dtds. Did I do this because I’m so arrogant as to think I can do a better job than Spring? No, I would much rather just use spring, but unfortunately my current client has forbidden the use of spring in a written standards document. Do they have atleast a good explanation as to why they have done this? No, but what can you do? Well you can do what I did, write your own dependency injection implementation. Of course there is more to this story that has lead me to this conclussion. My current client is also a big advocate of Test First Development. I personally do not think that this is a bad thing. I like a lot of the benefits you get from this methodology, but they have also placed metrics using Clover to all applications and they have a strict 85% coverage requirement. I understand the use of metrics to make sure your developers are developing with your methodology, but you could theoretically develop an application test first and still not meet the 85% target. What I don’t agree with is the fact that they treat this arbitrary number as a strict requirement rather than weighing the relavance and using the target as a guideline. On top of that, they are anti-opensource and have written a series of homebrew frameworks including their own light-weight struts (I use that term lightly since it is mearly one level of indirection on top of the j2ee servlet framework), a web-services framework (they are also anti SOAP) and a peristence framework (which is merely a jdbc template which provides no additional functionality other than it implements dbcp and actually limits your use of jdbc). Anyway, the point that I’m trying to get to, through my rants and ramblings, is that their light-weight struts framework is very difficult to test, because it does not provide access to the controller’s constructor or setters to be able to inject your dependencies in order to mock those dependencies out (yet the reason they give for developing their own mvc was because struts wasn’t testable). Therefore on top of my DI framework that I created, I also rewrote (rerouted) some of their mvc framework to allow me to inject dependencies through the constructor, thus making it much easier to develop these controllers using a TFD methodology. In the end I’ve wasted much time writting my own DI container so that I can meet their test coverage requirements. Atleast I had fun writting it and also added prototyping allowing me to inject runtime dependencies into my container managed objects, something I’m not for sure spring supports.