The Web is RMR not MVC
96 December 2008 by Ian Davis
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 :)
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.
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(), …
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.
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?
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).
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.
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+M…
RMR (and indeed many web frameworks) seems to get dangerously close to “shape the user interface to the data” – the same as we saw at various times over the last 25 years with ADT and RDMS instant-interface frameworks and tools.
IF your underlying data is sufficiently simple (e.g. list of atomic ‘things’, such as address book entries), and IF you get to design the underlying data layer rather than it being given by a third party or legacy system (no APIs!), and IF you have designed the data model based on an understanding of your users’ understanding of the concepts, and IF there is only one type of user, and IF the user needs only one way to see the data, and IF that way does not change over time; THEN resource=interface is fine.
In fact this does work surprisingly often (given the number of IFs), and when it does, the simplest framework possible is clearly best for efficiency, maintainability, etc.
However the danger is that one or other of those IFs may not be true of a project and if you have become wedded to “resource=interface”, or the conditions may have held when a project starts, but over time it gets more complex.
So, IF you are prepared to hold RMR (or similar framework) lightly, not as point of doctrine and IF you are ready to refactor, modify and otherwise go down a more complex route (although certainly not necessarily ‘standard’ MVC) when circumstances change; THEN I agree with you ;-)
Well, my point (which I never made clear in this post, nor found the time to follow up in the planned second post) is that in a web application the Controller is the HTTP protocol itself. It’s the only mediation mechanism between the user input (GET/POST) and the model.