The presentation by Tom Opgenorth on Monorail was fantastic. It gave me ideas as to how to use Microsoft’s MVC in the current project I am working on, and gave me ideas as to some of the pain points of MVC and IoC frameworks.
The number one thing that has always bugged me about MVC and IoC is that everything resides in an xml/config file. The concept of being able to plug and play is fine with me; you can change things out without recompiling. A simple flip of a switch and *shazam* it’s all hooked up and running.
The problem is in the details.
a) Post-deployment troubleshooting:
When stuff inevitably breaks (I know I am the only one who has ever written code that has broken… but please bear with me), it is often difficult to resolve where the break happened or how to fix it. I know you can write applications more robustly but, when the story or use case has been coded… we’re forced to move on. The business value of writing an application that can heal itself or give meaningful feedback when "stuff" happens is, far too often, lost on product owners or business analysts. The functionality delivered to the end user is so high on the list (and, rightfully) that these sorts of details are neglected.
b) Post-deployment maintenance:
A side issue is that, in many of the larger organizations I have worked at, developers are expected to hand off the application to a deployment/maintenance team to manage. Far too often there are so many other applications on their plates that this type of application complexity puts me squarely back in the seat of managing the application when it breaks. Having configuration files for non-developers to be able to touch and muck with increases the fragility of a deployed application. Just reminds me of installing any number of crazy combination dependencies to get some Linux applications working properly on older versions of Linux (that didn’t have aids to help manage dependencies). This puts me squarely back into the saddle of maintaining this application or into documentation hell and introduces a dependency of the client on my services. Great for job security… if that’s the type you are looking for.
Lack of Testing around the "And then magic happens":
Separating out dependency instantiation from class implementation is a good idea. It helps set up an environment where people can work on/test parts of the system independently. But… with most IoC Containers I have seen (though this is only through demonstrations), the wiring up of the configuration of what class to instantiate the dependency is often lacking testing. This can result in an exception being thrown at run-time (arguably the worst time to throw unhandled exceptions) if no dependency is actually wired up. Maybe this is a call for a profiling application to check class dependencies and ensure that they are all wired up within the IoC framework and included as part of the release criteria for the application?!?!