Rails is not MVC

Exactly. OP offers a great article and commentary, and then arrives at the completely wrong conclusion. Like it or not, MVC is in the vernacular now, and it means any framework organized in model-view-controller structure – regardless of whether the app has stateful views.

A better conclusion perhaps would be to distinguish "stateful MVC" from "stateless MVC"?

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

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

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)

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.

I'm a Rails person, but I always respected the Django community. The fact, that you were clear with the MVC vs MTV approach since the beginning was one of the reasons.

pyramid is also following you there however you are right on causing confusion.

Are there any notable Python Frameworks that don't use MTV?

I have never fully grokked the architecture of web "MVC" frameworks. I now realize it was because of confusing naming.

For people who are familiar with the MVC pattern for desktop UI's, I think it is confusing to use the same name for web frameworks which follow a different architecture. On the other hand, for people without this background, for whom MVC means "like rails", it is probably more confusing to introduce a new name for the same.

> We lost that argument because no one cared

I think the Python community in general adopted that Concept though. The term "view function" is much more common than "controller method". Flask at one point even had the term MTV in the docs I think but we just got rid of it and no longer mention any design patterns there. It's just too much confusion.

Often enough people jump into the IRC channel and ask how to use "MVC" with Flask and what their question really boils down to is how to use a class instead of a function. Design patterns are good and well, but I think documentation should encourage more thinking outside the box.

I don't see how you can call this a subtle pattern distinction.

MVC contains 3 words: 'model', 'view' and 'controller'. These interact completely different in "real" MVC and in most "MVC" web frameworks.

The point isn't the observer pattern; that's just a tool. The point is that in MVC, only the controller talks to the model. The model in turn notifies the view, but doesn't know anything about it. In Rails & co, the controller knows a lot about the view. Also, there typically is only one view per controller. These limitations are not there in real MVC, because the controller does not know anything about the view.

This nearly complete independence of the three components of MVC is what makes it good. Exactly this is what traditional web frameworks don't have.

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 spaghetti. The key insight is "asynchronous" rather than "let's do REAL MVC!"

I've seen this obsessive focus on taxonomy of solutions divorced from specific problems in domains outside computing. I suspect it's a cultural thing. Some cultures obsess over gadgets more than others. That works out until people start arguing about who has the shinier toy, instead of actually using said toys as tools.

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.

Here are the definitions as I know them:

MVC - MVC is separated, Models can notify Views.

Model1 - mixing all code in one place, often seen in first PHP apps

Model2 - separation between Model and View, I think Struts started it. Rails made it prettier.

Yes, the gain from correcting the confusion may be small. However, the topic of JavaScript MVC is going to be huge soon, good to know the differences.

Hate to say this but I have to agree with you.

It's a nice concept/patterns/principal but it caused a lot more confusions.

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.

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.

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 less fundamental in "Server-side MVC" than the other components. The first step towards a framework is having a controller than can serve up different views in different situations: if your form doesn't validate, you can serve the form up again or you can serve a different page if it does... I remember the "bad old days" of cgi-script programming where the form and the form processor were in different scripts and you couldn't do server-side validation the right way.

Ruby has a particular strong role for the model, which has some advantages and some disadvantages.

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.