I once presented Rails as an example of "MVC" in my software architecture class the the Prof. kind of ripped me apart saying either Rails it not MVC or I am misinformed.
After a lot of research I realized that the true MVC architecture is not something that Rails implement. In MVC the views are updated when models change without the controller in between. Something like YUI App framework is true MVC in that sense, but not Rails.
The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context.
While your professor was right he's also a moron for being overly pedantic and ripping you apart.
In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context.
Isn’t this a bit like saying that in the context of mountain rescue (which involves rough and steep terrain) cars have to be adapted to fit? Cars simply aren’t useful in that situation, and while helicopters are great, they aren’t cars any more. Moreover, the innocent belief of a five-year-old that a helicopter is just like a car but with some rotor blades on top does not mean that people with engineering degrees should start calling them cars because the meaning of the word “car” has been diluted.
Not quite. The apps still have state. That is what we today call web apps, have state. Web pages and REST documents probably shouldn't have state, or have very carefully managed state -- different from say a spreadsheet with a (continuously updated (ok, call it "reactive" if you must)) graph.
So, if you want to build stateful apps on top of web and http (which are stateless) -- you'll end up playing with the same concepts as that of MVC -- but you need to adapt.
I agree you probably shouldn't adapt the MVC pattern (it's a pretty high level abstraction) -- but you'll have to paper over http somehow.
So far building fat clients, lately using either javascript, objective-c or java/dalvik -- seems to work better than sticking the state in a cookie and pretending everything is ok.
In other words: MVC is still valid, and the adoptions aren't really to MVC -- they are to the surrounding framework. I'm not quite sure how that fits with the mountain rescue analogy, though.
> In MVC the views are updated when models change without the controller in between.
Wait, does that mean Wicket is a MVC framework after all? I thought frameworks like Rails, Grails and Spring MVC were classic MVC frameworks, while Wicket was View-first (whatever that means), but in Wicket, View and Model update each other directly.
Yes, ironically the web frameworks that explicitly say "we're not MVC" tend to be much closer to actual MVC than the ones that call themselves MVC frameworks.
After a lot of research I realized that the true MVC architecture is not something that Rails implement. In MVC the views are updated when models change without the controller in between. Something like YUI App framework is true MVC in that sense, but not Rails.