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

31–40 of 49 posts

Re: Rails is not MVC

#31

Post by alex3t »

strictfp wrote: post #10

In my opinion the term MVC should be avoided. It was badly defined from the very start and has been misused to the point where it is mostly a buzzword. Beginners spend precious time trying to understand the concept using flawed guides and tutorials, whereas experts dismiss the term as being to unspecific. My favourite CS teacher tought us MVC simply by suggesting that we made a command-line client before building a G…

agree. Last time when I thought about MVC was interview years ago(hope nobody today ask same questions). As Rails developer with 4 years experience, I'm not care now about these things, I'm care about product.

Re: Rails is not MVC

#32

Post by jerf »

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 trying to hide network-based RPC behind the same abstraction layer as a simple function call is a profoundly bad idea, inviting a pattern of thought into your head which will encourage you to neglect the client-server component of your solution is also a bad idea. Even if you think it won't fool you that badly, why let it fool you at all? Why not actually think of it in the proper terms?

Some combination of MVC and client-server is possible, but even then further specification is required to be clear about what you're doing, because the client/server can be placed in arbitrary locations in patterns, and particularly for web environments one must be careful to specify which components of the various elements are the canonical ones, where they live, and which are ultimately just cached copies.

Further it appears to be empirically the case that people who get MVC-happy begin to mistake MVC for being the one and sole and singular definition of good design, and start sticking it places it doesn't belong, while neglecting the proper design practices that should be used. MVC is actually a brain bug; seeing someone go on about MVC is an almost 100% accurate marker for someone who doesn't deeply understand design at all, and just has a hammer and is hitting things with it.

Re: Rails is not MVC

#33

Post by gruseom »

strictfp wrote: post #10

In my opinion the term MVC should be avoided. It was badly defined from the very start and has been misused to the point where it is mostly a buzzword. Beginners spend precious time trying to understand the concept using flawed guides and tutorials, whereas experts dismiss the term as being to unspecific. My favourite CS teacher tought us MVC simply by suggesting that we made a command-line client before building a G…

I was hoping someone would point this out. I tried many times to understand what MVC meant and came to the conclusion it was ill-defined. The M and V are easy to understand: separation of presentation from content. That is what your teacher was teaching. But the definitions of what C is and how it interacts with M and V are so vague and varied that I eventually threw the whole concept out. (Note that there's no C in your teacher's example. Both command-line and GUI programs have control responsibilities. Actually, both have views too. Yet the distinction is still instructive.)

I believe we should focus on first principles on the one hand (in this case, separation of concerns) and specific problems on the other. Trying to formalize first principles into proto-programs has proven to be a mistake. You end up with ersatz abstractions that don't stand up to interrogation - things that take the form of something precise, but aren't precise. That is confusing, leads to a great deal of useless secondary thinking like "is my program really MVC", and inevitably bogs down in semantic disputes. The more one focuses on such stuff, the less one focuses on real software. It makes you worse at building systems, not better.

First principles are imprecise, but simple and profound. They guide you very well if you let them. Specific designs are precise, but always relative to the specific problem they're trying to solve. Both these levels of abstraction make sense; it's the in-between layer that leads to confusion and should be eschewed. But it's perennially seductive to people who are attracted by the thought of figuring software out at a meta (but still technical) level.

Edit: skimming through the comments in this thread shows how differently, and how incompatibly, people interpret these terms. They exist to provide "a common vocabulary so people can know what they're talking about" (the standard rationale for patternspeak), but the facts on the ground are Babelian.

Re: Rails is not MVC

#34

Post by troels »

PaulHoule wrote: post #30
extension wrote: post #28

Here is my personal understanding of the principles of MVC, without regard to any specific platform or implementation: The model is an API to the domain of the application that is not coupled to anything else. It is suitable for use with a user interface, automation, or as a component of a larger model. If the application domain is about storing data, then the model will provide access to that data and enforce its va…

People have been confused about MVC for a very long time. This article should have come out back in 2003. Struts, Ruby-on-Rails and most (if not all) of the other server-side web frameworks have always been something very different from the original MVC implementation in Smalltalk, and in fact, most "MVC" implementations in GUI systems deviate in some major way from the original. From my viewpoint, the "model" is les…

Interesting point there. I haven't thought about it that way before, because intuitively the model appears to be the most important. And of course it is when you look at the application as a whole, but from a http perspective, the controller is the pivotal point. If you begin to think about the model as an external service for the web application, clearly the controller becomes the most important element.

Re: Rails is not MVC

#35

Post by eddieplan9 »

hello_moto wrote: post #19

Is JavaScript MVC really JavaScript MVC (I've never used any so I don't know)? And is MVC the right pattern for rich UI app (GUI or Web client)? The last time we tried to use MVC in GWT app, it didn't work out quite well. We decided to use MVP + EventBus instead. These days the MS camp came up with MVVM (a variation of MVP or more closely related to Presentation Model, which I think MVVM is borderline architecture as…

I have used Backbone to build a rich UI app, which would be way beyond my capability and patience level if it was not for the design decision to strictly adhere to MVC. The app is about presenting scientific data in multiple forms, and allowing user to interact with the data and see the outcome of an action instantly. Think Excel with data-driven charts and lots of them. Adhering to MVC allows me to wire models and views up once properly and then forget about the views to focus on the data. It also makes it easy to add after-thought extra views easily without the need to find places to add the wires. Sorry the app is for internal use so I cannot post a link to it. The take-home message for me was that MVC is about separation of concerns to reduce complexity. It becomes an obvious choice when an application is complicated by tangled lines of dependencies across components.

Re: Rails is not MVC

#36

Post by nakedslavin »

what a strange feeling this post gave me. i've read it, then i thought about other frameworks, even wanted to argue, that purity in terminology is overestimated, and you know what? who cares.

i dont know if thats because client side frameworks are becoming much more important, and talks about differences between django and rails sound more and more pathetic, or maybe its a personal thing and i just need to get some sleep )

Re: Rails is not MVC

#37

Post by hello_moto »

eddieplan9 wrote: post #35
hello_moto wrote: post #19

Is JavaScript MVC really JavaScript MVC (I've never used any so I don't know)? And is MVC the right pattern for rich UI app (GUI or Web client)? The last time we tried to use MVC in GWT app, it didn't work out quite well. We decided to use MVP + EventBus instead. These days the MS camp came up with MVVM (a variation of MVP or more closely related to Presentation Model, which I think MVVM is borderline architecture as…

I have used Backbone to build a rich UI app, which would be way beyond my capability and patience level if it was not for the design decision to strictly adhere to MVC. The app is about presenting scientific data in multiple forms, and allowing user to interact with the data and see the outcome of an action instantly. Think Excel with data-driven charts and lots of them. Adhering to MVC allows me to wire models and v…

Mine was business LOB with lots of forms and lists and updates from the back-end. All as a single-page app.

MVC got overwhelmed at some point and forced us to switch to MVP, which apparently the more widely accepted pattern for GWT apps.

Re: Rails is not MVC

#38

Post by endtime »

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…

>I think "view" is a crappy name for that since it doesn't define presentation

http://en.wikipedia.org/wiki/View_(database)

Re: Rails is not MVC

#39

Post by zzzeek »

endtime wrote: post #38
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…

>I think "view" is a crappy name for that since it doesn't define presentation http://en.wikipedia.org/wiki/View_(database)

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.

Re: Rails is not MVC

#40

Post by endtime »

zzzeek wrote: post #39
endtime wrote: post #38

Earlier quoted context omitted.

>I think "view" is a crappy name for that since it doesn't define presentation http://en.wikipedia.org/wiki/View_(database)

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.
Post reply on HN