I Love Dependency Injection But ….
I’ve burned myself so many times with dependency injection in the past. It make me nervous when I see a complex software product comprised of multiple projects and dozens of libraries without any comprehensive test that double checks the wiring. As our wiring grows and changes over time we need to continuously verify that everything works together. Dependency injection is one of the most valuable patterns in software development. Spring.NET is a necessity in today’s world and has great power that we need to harness in our products. With software products getting bigger and bigger, Spring.NET turns into a double edged sword that can hurt us especially if we cannot prove that every object is wired properly.
Beanoh.NET is a powerful tool for designing and maintaining Spring.NET configurations. One time I had an object named “messageSender” and that object controlled an HTTP connection to a web service by specifying a timeout for connecting and reading the HTTP stream. One day I needed to up the read timeout but for the life of me I couldn’t figure why the call was timing out after 15 seconds even though I’ve increased the timeout to 30 seconds. I spent hours looking into the documentation of the HTTP sender and debugged the code to no avail. In a moment of despair, I ran an Agent Ransack search through the whole web application package for the word “messageSender” and found two objects with that name one with 15 seconds timeout and the other with 30 seconds timeout. Each pulled from a different library. Wouldn’t it be awesome if my continuous build failed with a message saying “a duplicate object definition was found with the name of ‘messgeSender’. Are you sure you want them overriding each other ? ” If I was using Beanoh.NET it could have identified this duplicate bean.