Model + Controller = Unified Resource?
Posted by Adam Wiggins on April 16, 2008 at 12:05 PM
Harry Fuecks thinks MVC might be overrated. In a world of web resources, why not combine models and controllers together? Imagine replacing ActiveRecord (or my new favorite, DataMapper) with a server-side version of ActiveResource. GET, POST, PUT, and DELETE are filled in automatically, and you can extend their functionality and add suport methods.
He also argues that what we really want is RUD, not CRUD. The distinction between create and update is subtle, and hardly important if you think of resources as documents. (Document-oriented databases are poised to replace relational databases - we may soon be thinking in terms of documents instead of records even on the backend.) Think of your filesystem, the seminal document-oriented database: when you write a file, does it matter if one exists already? Not usually. File.open('test.txt', 'w') { |f| f.puts "hello" } behaves the same way regardless of the whether a file by that name previously existed or not.
This server-side ActiveResource might look something like:
class Post < Resource has_one :author has_many :comments, :dependent => :destroy def get super end def put super end def delete super end end
It provides both the controller and the model. The superclass for each of the three public-facing methods handles writing it to the backend store; the relationships described by has_* give both the routing config and the database relationships.
This is more speculation than a real idea, but I found it to be an engaging thought experiment.
Comments
There are 3 comments on this post. Post yours →
We've been playing with something like this a little bit in merb. With the new datamapper you can actually do "include DataMapper::Resource" in your merb controller and persist your controllers. Basically merging your dm model with your merb controller into a unified resource.
But this also limits you to one resource per controller mindset. I'm actually of the opinion that we need to decouple the notion of a REST resource with one model. A REST resource a lot of time needs to encapsulate a number of models.
I like the lines you're thinking along. And you may be right about document-oriented databases taking over. Google's App Engine provides what I would call a document-oriented database. When that becomes available in more languages, and the api is implemented on more distributed platforms, I think it will be a very popular way to write web apps.
I'm with you on the document-oriented database model overtaking the relational one of yester-year. Those that have no idea what they are should really get with it.
As for the Resource based models... what about when you take the model class outside of a web-based application structure? A Book web resource class is much different then a Book class by itself.
Thats probably one of my favorite features of Rails, that I can abstract out these classes into Rake or separate applications entirely. Not losing "data model" functionality and logic.
With that said, I do like the idea of -having- the option to merge the M and C together if needs be. It makes sense if you think of them as "data resources".
Post a comment
Required fields in bold.