Beyond Inversion of Control

There is no doubt about it: the MVC pattern has taken over. In my view, it just has one "minor" flaw: tight coupling. Every time you insert a reference to another class, it's just gonna sit there forever until you, the developer, decide to take it out again. To ameliorate this, Inversion of Control was introduced. It uses dependency injection at runtime, so the control of the dependency is out of the hands of the developer. Some people seem to find it hard to understand IoC, but it's really that simple. Who or what is in control, now that the reference has become all soft and fuzzy? You've guessed it: your config.conf. Or your wysi.wig. Something horrible at least. Well, that's your prize for joining the MVC movement. But wait, wasn't there some way to explain to your boss that you're still a decent programmer? Yes, through reference! He or she is probably looking at all your LinkedIn endorsements! Good job! Cudos to you!

Catch my drift? There is not a problem to be solved in MVC, there are references to be made in the same way your boss knows you're the best (for that rate). He or she has some kind of relationship with you, or knows (of) someone who does. This makes you partly indispensable, at least for the moment. The same was true for your dependency when you coded it. It had good reason to be there, but was replaceable at some point. When you keep track of this in a static way in another part of your life, it is still just sitting there: not in your code this time, but yes, sitting and waiting, like the money in your bank account, waiting to be plucked from its cozy nest. It hasn't become any more fluid. Really. Back to MVC: in fact, you shouldn't model anything. Software is better off without any reference to humanity. It should, as they say, "just work". Right? Right.

The problem with MVC is that it approaches abstraction from the wrong end of the spectrum, namely data. I forgot the reference, but I'm quite sure it was Jan Lehnardt who mentions somewhere that data is "fluff users want to see" (go ahead, google it yourself). MVC starts with the M, which is a way of saying: you go boy, draw all that putrid slime your client put somewhere (probable in some unwieldy RDBMS) into your code and pee over it some more, THAT is what your hacking life here on earth revolves around. So why not put the C in front? You're in Control, right? And throw out the V while we're at it... you're a programmer, remember? V is for designers. And what about that M? Do we need it in there at all? We have all kinds of beautiful (relational) solutions for modeling data, right? Oh yeah! Talking about Inversion of Control! You were never meant to be in Control in the first place! So throw out that C too! Wooo! Go nuts! Tell me, what do you get?


  1. Before anyone else does, let me add that one of the main reasons to have IoC in MVC is for testability and ease of development. I was being ironic for the sake of questioning MVC in general, not IoC in the context of MVC. It's still a valid point, as Spring or Beans will always lead to configuration hell.


Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

JS Journey into outer space - Day 5

JS Journey into outer space - Day 3