MVC Obscures the Mechanics of the Web


24 September 2007 by Ian Davis

I dug up some links on the mismatch between MVC and the Web:

It’s hard to explain in simple terms why MVC is such a poor pattern for web development. I don’t claim any particular success in converting people away from the lure of GUI patterns but in my experience the hardest task is resetting people’s internal model of a web “application”. MVC works pretty well in the traditional GUI where you might have an item (e.g. a document) that you wrap with a model and expose with different views (as an icon and label in a treeview, a larger icon in a window, an editable word processing view, a print preview with different font metrics, a thumbnail presented when the mouse hovers over the icon). You add a controller to enable multiple interations in various views (selecting with the mouse, selecting by using tab key, activating an icon by double-clicking, activating an icon by pressing enter, modifying content by typing on the keyboard, copying and pasting content of the document, copying and pasting the document itself as an icon, dragging, dropping). Yes, in that complex world MVC can help to simplify the programming.

But the Web isn’t so complex. You have resources, which could be models in MVC. But you only have a handful of interactions and they’re all the same for every resource. You also have only a single way to view an item. You could possibly stretch the notion of representation to encompass multiple views but there’s nothing like the huge presentational differences that you get in a desktop GUI – just minor variations of markup language. MVC just obscures the mechanics of the Web, forcing the developer to write code that isn’t necessary and layer on more complexity when the mechanics start leaking through. Once you break your infatuation with MVC you find yourself writing much simpler code that mirrors the operations that drive the Web, and you actually start understanding a bit more about HTTP, the protocol that most frameworks try to pretend doesn’t exist.

4 thoughts on “MVC Obscures the Mechanics of the Web

  1. Jonathan Rochkind says:

    Interesting argument, that doesn’t totally convince me (but of course, I’ve been writing MVC for years, which gives me a prejudice).But just be sure you consider MVC as represented by it’s _best_ examples too, not just it’s worst. Ie, yes, Struts is a monstrish nightmare (or is that a nightmarish monster), but consider a well-designed MVC framework too. Say, Rails.

  2. iand says:

    Yes, I’d agree that Rails has learnt from the mistakes of other MVC frameworks but my main point is that MVC isn’t appropriate for the web in general. I can see a case in the client-side Javascript of an AJAX application, but not on the server-side.

  3. Jonathan Rochkind says:

    I guess on thinking this through further, I start to a little bit more see the point, although I’m still suspicious.But I guess what I’d want to convince me is NOT an argument “See, this is why MVC is all wrong”, but instead a proposed solution: “This is a web framework that we think is more resource-centered and suited for the web, using patterns other than MVC.” If someone is going to try to convince me that the only thing suited for the web is writing everything from scratch (and without using design patterns at that, but just making it up as you go along), they’re going to have a tough time. I’m pretty convinced of the power of good design patterns implemented in a good framework for any significant development. For a whole bunch of reasons.So, if not MVC, than what pattern? And demonstrate that ‘what’ in a good framework. And maybe I (and other doubters) look at it, and say, gee, you’re right, that’s great. (But I suspect that it will end up being a _variation_ on MVC. Which is why I want to see it demo’d, right? Talk is just talk.) The most convincing arguments in your links were about the need for resource-focus, and to me, MVC isn’t incompatible with that at all, nor is MVC too ‘heavy’ for that, but the ‘C’ and ‘V’ end should probably be constrained/supported to a REST interface more.

  4. iand says:

    Doesn’t REST define the pattern you need: resource/representation? Your application uses the URI to locate the appropriate resource and asks it to produce the appropriate representation.I quite like the way Konstrukt ( does it although they confuse the issuse by using the term controllers for what I would call routing. Tonic does more traditional routing to resources. See Keith’s post for some useful information:

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: