Flutterby™! : MVC 2011-08-20 14:05:57.832675+00

MVC

2011-08-20 14:05:57.832675+00 by meuon 5 comments

MVC (or whatever you call it in your techno-theocracy) = How to do simple in a complex manner.

I think the paradigm/architecture works better in real-time local applications with event driven handlers better than it does for web-stuff, unless you are using lots of ajax-ish stuff. For basic web stuff it's like shooting cockroaches with a bucket full of Jello(tm).

I spend most of my time these days writing JS, getting much milage out of a MVCV (Model, View, Collection, View) pattern where the second V is analogous to the controller in more typical MVC. Lucky for me, the ORM in this case is an API built and maintained by somebody much smarter than myself.

In once case I can't get an MVC to allow me to do "order by field(type,'kWh')" to put the kWh readings first, but it's trivial n SQL itself.

I think that one of the issues is that in a good database you put the controller in the database (ie: triggers and VIEWs), but generally the model is the database tables, the view is the web pages, and the controller is the code which updates the database while maintaining "business rules", the things that go beyond referential integrity but are still necessary to keep the database in a meaningful state.

However, most MVC frameworks I've seen add shitloads of cruft around those simple distinctions in ways that make me wanna scream "just give me a freakin' SQL statement already!".

The scaffolding is heavy and complicates tasks that should be easy. Frameworks are a good idea, collections of tested bullet proof code is a good idea. I'm watching experiments with two MVC frameworks at work. The idea of separating the presentation layer from back end makes sense, it's the middle layer I seem to be having conceptual and practical issues.

I don't have any illusions that the simple "controllers wire up database objects and template files" model I'm using most days at work is classical MVC, but I still want to challenge this. In the web world, you do find plenty of frameworks and paradigms that overcomplicate the task at hand, but when web people talk about using MVC for most things, I think they're pretty much on the money with what they mean by "MVC". It keeps things clean to separate some fundamental concerns and have a good conceptual template for a given task.

I was just reading this NYT Magazine piece on "decision fatigue" linked over on MeFi. I think saying "we're going to put our view here and our data modeling here and the structure of our application here, mapped to certain conventions" is a really solid way to avoid burning your mental energy on the wrong decisions. It can lead to some boilerplate, but a project doesn't get very big before the effort to put in a little scaffolding is rewarded many times over.