5 ms·

MVC, PVC and (¬M)VC

66 points by raganwald 16y ago

grncdr 16y ago
I had to read this in a bit of a hurry (on my way out the door) but I would've liked to see an abstract up front in the essay (essentially the last paragraph first). Also, for doing a JS based SPI, what's the preferred solution for a RESTful domain logic server? Is there a framework out there that simply doesn't contain the concept of a view/template?
- raganwald 16y ago
  Sinatra? But before implementing a 100% pure, view-free server, consider that delivering an HTML view for each resource can be handy for testing and administrative tasks. It's the exact same information one might get from JSON or XML or YAML, but it's still nice sometimes to be able to fire upa standard browser window and do stuff on the server directly.
  - lusis 16y ago
    I think view-free is a bit of a misnomer. Even in sinatra, you could consider JSON as a "view". You can still test that too with browser plugins like "REST client" for firefox or htty on the command-line. What it forces you do to is make sure your API is very clean, very succinct and exposes all critical portions of the backend. Really all we're talking about is the model being a REST service instead of a database model.
- rubinelli 16y ago
  There's a handful. In Java, you could use http://www.restlet.org/ http://www.restlet.org/ or http://jboss.org/resteasy http://jboss.org/resteasy ; alternatively, you can use a framework that does have templates but makes it easy to return a serializable object directly from the controller, like http://playframework.org http://playframework.org or http://vraptor.caelum.com.br/en/ http://vraptor.caelum.com.br/en/
- jamesbritt 16y ago
  "Is there a framework out there that simply doesn't contain the concept of a view/template?" Rack. Though as features are dropped, the idea of something being "a framework" gets increasingly market-y.
jamesbritt 16y ago
Weird. Previously submitted here: http://news.ycombinator.com/item?id=1801632 http://news.ycombinator.com/item?id=1801632
- raganwald 16y ago
  Not weird, timing is sometimes everything. Sometimes a perfectly good essay is submitted after everyone goes to bed, or they are too busy to read a long item so they don't vote one way or the other. If the post fails to get that crucial push of votes in the first hour, it dies. The exact same thing resubmitted first thing on a Monday morning gets an entirely different reception. I guess that's just how things go, I hope people don't take this resubmission as spammy behaviour or as trying to steal karma from you :-)
  - biggitybones 16y ago
    Usually when you submit something that's already been submitted semi-recently, it'll send you to that submission and up vote it automatically. It matches the URL I'm not sure if theres a timeframe for this - I've seen it on something as long as a few months.
    - wwortiz 16y ago
      That is true if the urls are the same but in the previously submitted one #readme is appended and this one lacks that. I believe that dups with the same url are caught as long as they are in memory on the server.
      - icey 16y ago
        The URL comparator appears to be a simple (case-sensitive!) string comparison. There are many ways around the dupe filter.
  - jamesbritt 16y ago
    ". I guess that's just how things go, I hope people don't take this resubmission as spammy behaviour or as trying to steal karma from you :-)" Oh, sure! No, actually I was just surprised the URL dupe-matcher didn't catch it. I see now they have a minor difference, though it indicates how easy it would be for someone to bluff the dupe finder if they wanted to. Mainly, though, I'm glad there's discussion on your post.
lusis 16y ago
I actual favor this model in many cases. I've always thought that MVC was still too tightly integrated for my tastes. Why should we treat our internal applications as any different than our interaction with external ones? I realize this is "self-contained" but the same logic applies.
vog 16y ago
This is a great summary with a clean wording. I always shudder when web projects / frameworks claim to do MVC when they're in fact doing something different.
jashkenas 16y ago
Awesome article, but be careful of tying your JavaScript applications (SPI, in the essay's parlance) too tightly to specific URLs and HTTP requests, as demonstrated in his Roweis example: .view('institution', { route: 'institution/:_id', gets: { institution: '/institutions/:_id', m_and_e_list: '/institutions/:_id/me' } }) Raganwald explains that moving to "#institutions/42" will make 2 GET requests, one for the institution, and one for the M&E list. But there's no real reason to cargo-cult a traditional Railsish-request-response-webpage interface onto an entirely client-side application. Now, besides the fact that making 2 HTTP requests for a single institution is less than ideal, what happens if you want to load a handful of institutions in the background, without changing the URL? What happens if you'd like to not repeat the institution request if the data has already been loaded once? Compare this to the equivalent with full-blown models, using something like Backbone.js: // Load the initial data. Institutions.fetch(); // Only load the data if it's not already present. if (Institutions.isEmpty()) Institutions.fetch(); Being able to work with model data in sophisticated ways is the heart of JavaScript applications -- if you omit models from a JS app, it might feel like a simplification at the beginning, but as soon as you want to perform an interesting computation, optimization, or rendering trick, you'll start to regret it.
- raganwald 16y ago
  Exactly why I advocate PVC for anything beyond aping a web app. I wouldn't say there's _no_ reason to ape a web interface, but I hope I pointed out the drawbacks. I think we're in violent agreement. FWIW, I think you'll see backbone integration with Roweis, but it'll be easy to transition from (¬M)VC to PVC. We're deliberately trying to make Roweis easy to migrate, so having written the above, you ought to be able to switch to a proxy with ease. Now for your points. You say that making two HTTP requests is less than ideal. Well, that's exactly the point of decoupling the RESTful server and the application. If you control both, of course you can create a single RESTful call that delivers both sets of data. In which case both PVC and (¬M)VC can make one request instead of two. Caching is as an example of the strength of PVC. I'd also add things like long polling. Let's say we poll for updates to an institution. A change to its name ought to be reflected in a list of institutions along with any page or pages showing the details of the institution, plus any other entity that refers to the institution by name. A model or proxy for a model resource can handle long polling and all of the appropriate views can listen to it for changes so they can update themselves accordingly. (¬M)VC cannot handle that case at all.

66 points by raganwald 16y ago

I had to read this in a bit of a hurry (on my way out the door) but I would've liked to see an abstract up front in the essay (essentially the last paragraph first). Also, for doing a JS based SPI, what's the preferred solution for a RESTful domain logic server? Is there a framework out there that simply doesn't contain the concept of a view/template?

raganwald 16y ago
Sinatra? But before implementing a 100% pure, view-free server, consider that delivering an HTML view for each resource can be handy for testing and administrative tasks. It's the exact same information one might get from JSON or XML or YAML, but it's still nice sometimes to be able to fire upa standard browser window and do stuff on the server directly.
- lusis 16y ago
  I think view-free is a bit of a misnomer. Even in sinatra, you could consider JSON as a "view". You can still test that too with browser plugins like "REST client" for firefox or htty on the command-line. What it forces you do to is make sure your API is very clean, very succinct and exposes all critical portions of the backend. Really all we're talking about is the model being a REST service instead of a database model.
rubinelli 16y ago
There's a handful. In Java, you could use http://www.restlet.org/ http://www.restlet.org/ or http://jboss.org/resteasy http://jboss.org/resteasy ; alternatively, you can use a framework that does have templates but makes it easy to return a serializable object directly from the controller, like http://playframework.org http://playframework.org or http://vraptor.caelum.com.br/en/ http://vraptor.caelum.com.br/en/
jamesbritt 16y ago
"Is there a framework out there that simply doesn't contain the concept of a view/template?" Rack. Though as features are dropped, the idea of something being "a framework" gets increasingly market-y.

jamesbritt 16y ago

Weird. Previously submitted here: http://news.ycombinator.com/item?id=1801632 http://news.ycombinator.com/item?id=1801632

raganwald 16y ago
Not weird, timing is sometimes everything. Sometimes a perfectly good essay is submitted after everyone goes to bed, or they are too busy to read a long item so they don't vote one way or the other. If the post fails to get that crucial push of votes in the first hour, it dies. The exact same thing resubmitted first thing on a Monday morning gets an entirely different reception. I guess that's just how things go, I hope people don't take this resubmission as spammy behaviour or as trying to steal karma from you :-)
- biggitybones 16y ago
  Usually when you submit something that's already been submitted semi-recently, it'll send you to that submission and up vote it automatically. It matches the URL I'm not sure if theres a timeframe for this - I've seen it on something as long as a few months.
  - wwortiz 16y ago
    That is true if the urls are the same but in the previously submitted one #readme is appended and this one lacks that. I believe that dups with the same url are caught as long as they are in memory on the server.
    - icey 16y ago
      The URL comparator appears to be a simple (case-sensitive!) string comparison. There are many ways around the dupe filter.
- jamesbritt 16y ago
  ". I guess that's just how things go, I hope people don't take this resubmission as spammy behaviour or as trying to steal karma from you :-)" Oh, sure! No, actually I was just surprised the URL dupe-matcher didn't catch it. I see now they have a minor difference, though it indicates how easy it would be for someone to bluff the dupe finder if they wanted to. Mainly, though, I'm glad there's discussion on your post.

lusis 16y ago

I actual favor this model in many cases. I've always thought that MVC was still too tightly integrated for my tastes. Why should we treat our internal applications as any different than our interaction with external ones? I realize this is "self-contained" but the same logic applies.

vog 16y ago

This is a great summary with a clean wording. I always shudder when web projects / frameworks claim to do MVC when they're in fact doing something different.

jashkenas 16y ago

Awesome article, but be careful of tying your JavaScript applications (SPI, in the essay's parlance) too tightly to specific URLs and HTTP requests, as demonstrated in his Roweis example: .view('institution', { route: 'institution/:_id', gets: { institution: '/institutions/:_id', m_and_e_list: '/institutions/:_id/me' } }) Raganwald explains that moving to "#institutions/42" will make 2 GET requests, one for the institution, and one for the M&E list. But there's no real reason to cargo-cult a traditional Railsish-request-response-webpage interface onto an entirely client-side application. Now, besides the fact that making 2 HTTP requests for a single institution is less than ideal, what happens if you want to load a handful of institutions in the background, without changing the URL? What happens if you'd like to not repeat the institution request if the data has already been loaded once? Compare this to the equivalent with full-blown models, using something like Backbone.js: // Load the initial data. Institutions.fetch(); // Only load the data if it's not already present. if (Institutions.isEmpty()) Institutions.fetch(); Being able to work with model data in sophisticated ways is the heart of JavaScript applications -- if you omit models from a JS app, it might feel like a simplification at the beginning, but as soon as you want to perform an interesting computation, optimization, or rendering trick, you'll start to regret it.

raganwald 16y ago
Exactly why I advocate PVC for anything beyond aping a web app. I wouldn't say there's _no_ reason to ape a web interface, but I hope I pointed out the drawbacks. I think we're in violent agreement. FWIW, I think you'll see backbone integration with Roweis, but it'll be easy to transition from (¬M)VC to PVC. We're deliberately trying to make Roweis easy to migrate, so having written the above, you ought to be able to switch to a proxy with ease. Now for your points. You say that making two HTTP requests is less than ideal. Well, that's exactly the point of decoupling the RESTful server and the application. If you control both, of course you can create a single RESTful call that delivers both sets of data. In which case both PVC and (¬M)VC can make one request instead of two. Caching is as an example of the strength of PVC. I'd also add things like long polling. Let's say we poll for updates to an institution. A change to its name ought to be reflected in a list of institutions along with any page or pages showing the details of the institution, plus any other entity that refers to the institution by name. A model or proxy for a model resource can handle long polling and all of the appropriate views can listen to it for changes so they can update themselves accordingly. (¬M)VC cannot handle that case at all.