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?
MVC.

Comments

  1. wshagerMarch 28, 2013 at 4:29 PM

    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.

    ReplyDelete

Post a Comment

Popular posts from this blog

Abandoning hope... and XForms

Sometimes a decision must be made. I have invested many hours in a standard that is quite complex and tedious to maintain, and that was great fun, but enough is enough. Why did I invest in XForms when it took so much effort and time? Because I believe standards are good and good standards come from the W3C and the XML community. Also, I always had somewhat of an inferiority complex in IT development that I tried to compensate by using techniques supposedly invented for common folk, i.e. non-programmers. Both are bad reasons from where I now stand. I took up XForms because I was infected by the enthusiasm of a friend (who was even quicker to abandon it) about 3 years ago. At first I assumed it just used a model from which to infer a form. It turned out it was like a superset of HTML forms with options for displaying and validating data. This was largely taken up by HTML5, as we all know. The Model remains the core of XForms, but the W3C is slow to respond to innovations and t...
Read more

JS Journey into outer space - Day 5

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 5 It's time to add more operators. We already have map , but what if the mapping function returns another "container" value, like an array or observable? 🦉 In RxJS some operators like switchMap , concatMap , or mergeMap will expect a "project" function that returns an observable (or promise or array), but what happens then? First map is applied with the project function and after that the result is "flattened". In other words: when the returned (inner) observables emit, the mapped (outer) observable emits those values instead. Since RxJs streams have a specific async behaviour the flattening process takes concurrency into account: mergeMap will flatten inner observables whenever they complete, regardless of the order, but concatMap will preserve the order of the ou...
Read more

JS Journey into outer space - Day 4

This article was written as part of a knowledge sharing program I created for front-end developers. It builds up to creating reusable abstractions by studying async transducers. Day 4 Now we have modified transduce to handle async it's time to figure out how it can handle observables. Kickoff 🏈 First we need to pass the onNext function which kicks off the callback chain. In RxJs this is called subscribe instead, so let's rename the parameter and the callbacks to be more in line with RxJs : function transduce ( input , fn , subscribe , onError , onComplete , init ) { subscribe ( input , { next : ( cur ) => { init = fn ( init , cur ) ; } , error : ( err ) => { onError ( init , err ) ; } , complete : ( ) => { onComplete ( init ) ; } } ) ; return init ; } ; 🦉 Observables are considered a push-style of dealing with many values, while generators are pull-based. In...
Read more