Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails is not MVC

andrzejonsoftware.blogspot.com

Post reply on HN
Print view View original

41–49 of 49 posts

Re: Rails is not MVC

#41

Post by petersabaini »

zzzeek wrote: post #23

practicality beats purity, even though the Python frameworks are moving away from the "MVC" term it always felt like "MVC" to me, in that there are three distinct components - data objects (model), some kind of "load the model in response to a URL and display a template" (controller, what better name is there, I think "view" is a crappy name for that since it doesn't define presentation), then the "template", seems l…

The downside of muddying the definition of MVC is that it hinders communication about other design patterns that may actually make more sense for web applications, eg. Model-View-Presenter / Passive View

(Edit: if one cares about design patterns at all, that is. Otherwise it makes perfect sense to use MVC as the marketing term it has become and do whatever)

Re: Rails is not MVC

#42

Post by dasil003 »

jerf wrote: post #32
dasil003 wrote: post #9

I don't see the point in making these subtle pattern distinctions. The model notifying the view is not significant enough of an architectural criteria to merit its own term. I submit that there are dozens of such architectural variances between MVC frameworks and that defining high-level terms to codify those differences isn't helpful. I'll even take it a step further and suggest that a focus on taxonomy diminishes o…

Because it's not subtle. In particular, once you introduce "client/server" into the pattern, you've walked into a completely different domain, with completely different problems, solutions, and patterns, and in particular you suddenly have a great deal of concern over matters of latency and bandwidth, which MVC has no particular consideration for, because the entire paradigm was built on the desktop . Just like tryin…

Your reply is spot on, but wasn't the time raise this issue 7 years ago when Rails was released? Or maybe earlier if Java frameworks were self-described as MVC? To try to push Model2 now seems like an impossible task with almost no reward. It's like complaining about common usage of the word "hacker". It serves no one to take up arms, just let it be and move forward. Maybe coin a new term.

Re: Rails is not MVC

#43

Post by zzzeek »

endtime wrote: post #40
zzzeek wrote: post #39

Earlier quoted context omitted.

the "controller" in MVC is specifically tasked with responding to user input and persisting those changes into the model. So it's nothing like a database view either, which is traditionally read-only. Like a database view, a template organizes information from disparate sources into a particular presentational configuration - just at different levels of the stack. IMHO they are roughly analogous.

It's different, but it's not "nothing like it". I was explaining where the term comes from, since you didn't seem to know.

I'm familiar with database views, thanks.

Wikipedia credits Trygve Reenskaug with inventing the term "model-view-controller", he was a Smalltalk guy with Xerox at that time - I don't think there's any relation in the origin of that terminology to the notion of a "database view" - otherwise not sure what you're referring to here (here's a link to the original paper: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html)

Re: Rails is not MVC

#44

Post by mcdonc »

zzzeek wrote: post #23

practicality beats purity, even though the Python frameworks are moving away from the "MVC" term it always felt like "MVC" to me, in that there are three distinct components - data objects (model), some kind of "load the model in response to a URL and display a template" (controller, what better name is there, I think "view" is a crappy name for that since it doesn't define presentation), then the "template", seems l…

It's not splitting hairs at all. It's the definition of the pattern. The pattern was created for stateful UI systems, and it can't be emulated with request-response frameworks without UI state kept on the client side.

But that said, the fact that Rails (and Pylons, etc) called themselves MVC has rendered any definition meaningless, so it just kind of doesn't matter. Truth be told, it was already getting there long before web frameworks entered the picture when Java coopted the term to mean something it didn't in the 90s.

I prefer to use different terminology to avoid confusion, but if you wanna keep using "MVC" for your own stuff, I'm not going to fight city hall.

Re: Rails is not MVC

#45

Post by phamilton »

qaexl wrote: post #17
dasil003 wrote: post #9

I don't see the point in making these subtle pattern distinctions. The model notifying the view is not significant enough of an architectural criteria to merit its own term. I submit that there are dozens of such architectural variances between MVC frameworks and that defining high-level terms to codify those differences isn't helpful. I'll even take it a step further and suggest that a focus on taxonomy diminishes o…

Agreed. I can't find any insight or advantage in making this kind of a distinction. The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghet…

So could one call Rails a sort of "synchronous MVC" and javascript MVC "asynchronous MVC"?

Re: Rails is not MVC

#46

Post by qaexl »

phamilton wrote: post #45
qaexl wrote: post #17

Earlier quoted context omitted.

Agreed. I can't find any insight or advantage in making this kind of a distinction. The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghet…

So could one call Rails a sort of "synchronous MVC" and javascript MVC "asynchronous MVC"?

Hmm. Maybe? Seems impoverished to me.

Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.

By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.

Re: Rails is not MVC

#47

Post by jerf »

dasil003 wrote: post #42
jerf wrote: post #32

Earlier quoted context omitted.

Because it's not subtle. In particular, once you introduce "client/server" into the pattern, you've walked into a completely different domain, with completely different problems, solutions, and patterns, and in particular you suddenly have a great deal of concern over matters of latency and bandwidth, which MVC has no particular consideration for, because the entire paradigm was built on the desktop . Just like tryin…

Your reply is spot on, but wasn't the time raise this issue 7 years ago when Rails was released? Or maybe earlier if Java frameworks were self-described as MVC? To try to push Model2 now seems like an impossible task with almost no reward. It's like complaining about common usage of the word "hacker". It serves no one to take up arms, just let it be and move forward. Maybe coin a new term.

I've been raising it for a couple of years now.

And my beef isn't the terminology issue, though I would observe that if we decide to just declare that everybody using "MVC" is using it correctly, we immediately dilute the term to the point that it has no meaning whatsoever. It's more the brain bug part.

I wouldn't want to "fix" MVC usage, we'd be much better off simply eliminating it. It's almost never used in a productive manner. As for what to replace it with, that's easy: DRY, Don't Repeat Yourself. The particular structure of the code is always particular to your local problem, rarely fits into any particular paradigm when considered as a whole anyhow, and the real design criterion is DRY. I can't quite say it's impossible to have badly-designed code that is also completely DRY, but I would imagine it must be a challenge.

Re: Rails is not MVC

#48

Post by gaelian »

qaexl wrote: post #17
dasil003 wrote: post #9

I don't see the point in making these subtle pattern distinctions. The model notifying the view is not significant enough of an architectural criteria to merit its own term. I submit that there are dozens of such architectural variances between MVC frameworks and that defining high-level terms to codify those differences isn't helpful. I'll even take it a step further and suggest that a focus on taxonomy diminishes o…

Agreed. I can't find any insight or advantage in making this kind of a distinction. The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghet…

> It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti.

This is exactly the feeling I've been getting recently as I foray into writing my first Chrome extension. The asynchronous nature of XHR is ending up making my code a little more spaghetti-like that I would prefer. Would you happen to have any recommended resources for possible approaches to addressing this issue?

Re: Rails is not MVC

#49

Post by ftwinnovations »

Well technically most backend server MVC frameworks are using the Front Controller pattern. This is perfectly fine MVC though of course different from event driven, which matches a desktop application or JS based MVC.

Really this is just spitting hairs. The Front Controller pattern is perfectly suited to a non-event driven (node) backend system like rails or Zend framework, etc. Essentially the front controller is a router, similar to Backbone.js using hashbangs.

http://en.wikipedia.org/wiki/Front_Controller_pattern

Post reply on HN