Dec 06 2008

The Web is RMR not MVC

Published by Ian Davis at 10:21 am under Links and tagged as , , , , ,

Last year I wrote a short post titled MVC Obscures the Mechanics of the Web that drew together some other peoples writings on why MVC is poorly matched to the web. I didn’t give an alternative though, apart from indirectly in the comments. Now Paul James has written a succinct description of that alternative and christened it RMR – Resource Method Representation.

In RMR (which is simply REST as seen on the Web) the user interacts with resources using representations via restricted set of methods. As Paul explains, typically this is implemented as a set of classes representing the resources, a set of Response classes and some kind of routing to tie it all together. This is how frameworks like Tonic (written by Paul) and Konstrukt work. It’s also how my RDF framework Paget works, although that is very immature at the moment and doesn’t cover responses very well.

Here’s to banishing MVC from the web :)

7 responses so far

7 Responses to “The Web is RMR not MVC”

  1. # Jonathan Rochkindon 06 Dec 2008 at 3:15 pm

    I must confess I don’t understand the paradigm shift. Maybe I just have a more liberal conception of “MVC” than most people. But to me, RMR just sounds like another name for MVC. Resource = Model, Method = Controller, Representation = View. Even in that short essay by James, he says that! “So the representation is like a view in MVC”, “This acts like an MVC controller”.

    So what’s the big deal? What am I missing? How is this so different than calling it MVC still, how does this mean that MVC is poorly matched to the web? I’ve never ‘gotten’ it.

  2. # Alan Deanon 06 Dec 2008 at 6:17 pm

    Isn’t this just a question of naming?

    I [M]odel by resource, render representations with [V]iews and my [C]ontrollers have canonical method names like Post(), Put(), Get(), ContentNegotiate(), …

  3. # Ian Davison 06 Dec 2008 at 7:59 pm

    Hi Jonathan. Paul says Resource is like Model but not identical. There’s a different division of responsibilities between the components of RMR and MVC. They both do the job but I find RMR-like frameworks interfere less with what I’m trying to do.

  4. # Ian Davison 06 Dec 2008 at 8:03 pm

    Alan, interesting that your controllers have methods like Get and not your resources. Which component determines which methods are applicable to which resources? If I PUT a new representation to a resource URI what determines whether it changes the state of a resource or not?

  5. # Alan Deanon 07 Dec 2008 at 10:00 am

    Ian,

    To answer your question, the Model determines state changes. The Controller is there to bind the system to HTTP. The Model is transfer-protocol agnostic (in practical terms, the Model should not address HttpContext).

  6. # Paul Jameson 07 Dec 2008 at 6:47 pm

    Alan, partly this is just a question of naming, but then a difference in naming can lead to a difference in thinking.

    As Ian points out above, it is more about binding actions to resources (models) rather than to controllers and of removing (or limiting) the need for routing. You say “The Controller is there to bind the system to HTTP”, but I feel that there should be no need for any binding as long as we work with HTTP to begin with rather than forcing our ways upon it.

  7. # Andrew Daveyon 07 Dec 2008 at 7:44 pm

    I think the danger of MVC is that unless you explicitly use it as Alan does you default into an RPC design. (ending up with “URIs” like /customer/1/delete .. shudder!)

    I’m working on building a layer on top of ASP.NET MVC that brings a much more REST-focused approach.

    There’s a screencast showing the library in action here:
    http://www.aboutcode.net/2008/11/26/New+ResourceOriented+Library+For+ASPNET+MVC.aspx