Rails is not MVC

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 like a view to me - it's the thing you're viewing!<p>That the model isn't notifying the view through an event system is splitting hairs. The GOF book is much maligned I think because people insist on taking each pattern completely literally down to the last detail. GOF's pattern (GOF didn't create it but they discuss it on page 4, I thought I was crazy until I just checked just now) is specifically "MVC, and because we only know about C++^H^H^H Smalltalk graphical libraries and not very much about stateless HTTP systems yet in 1993, the model notifies the view of changes too, how else would it work ?" IMHO. It's an implementation detail, it's not the essence of the pattern.<p>So if a JS framework is now doing MVC that includes the concept of "model notifies the view", sure call it "classical MVC" or "model-notify-view-controller" (MNVC). Shrugs.

This is exactly why Django used to call itself an "MTV" framework (Models, Templates, Views) rather than an "MVC" framework - we realised that the classic MVC pattern didn't really apply to the Web.<p>We lost that argument because no one cared - in fact, I think we probably caused a whole load of confusion by not using the same terminology as all of the other frameworks.

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 ones ability to think fluidly about the low-level architecture and how to improve it to solve different problems.<p>This is quite different from (for example) the debates about the definition of REST. In that case there is a seminal paper and all kinds of subtle points leading to material benefits in web apps. What does Model2 have to teach us?

He is correct, but I doubt there is much confusion. The term MVC is used mainly to illustrate the separation of concerns, which is, IMO, the number one task for any framework.<p>Also, as far as I recall, the MVC pattern does not require communication between the models and the views, although it certainly allows it.<p>Looking at it from another perspective, MVC is a huge buzzword nowadays. It's simply not worth it to be conceptually correct for such a little gain.

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 GUI. There must be more practical ways like this which one can use to explain the idea.

Here is my personal understanding of the principles of MVC, without regard to any specific platform or implementation:<p>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 validity. But the domain could also be something that is not stateful per se, like interfacing with hardware.<p>A view is an independent component of a user interface for the model, and is tightly coupled to it. It allows humans to interact with some part of the model in some way.<p>The controller organizes views into a complete end-user application by instantiating them and connecting them to models. It should be minimally coupled to the details of views and models, and is optionally composable.

OP here.<p>There's one more reason why I want to clarify the situation with terminology.<p>Apart from being a Rails developer and running a Rails company I also teach Ruby on Rails at a university.<p>Obviously, I'm not the single source of knowledge for the students, however I want to clearly explain to them what is Rails, what is MVC and what is Model2.<p>It doesn't help me that when they go to any Rails website there's information that Rails is MVC, which is not.<p>Here and on my blog you can find comments from people who are confused with the current situation. I'm not expecting that today we're going to agree on any solution. I just want to point out that the definitions and their usage are not precise.

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.<p>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.<p><a href="http://en.wikipedia.org/wiki/Front_Controller_pattern" rel="nofollow">http://en.wikipedia.org/wiki/Front_Controller_pattern</a>

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.<p>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 )

Ceci n'est pas une pipe.

Is JavaScript MVC really JavaScript MVC (I've never used any so I don't know)?<p>And is MVC the right pattern for rich UI app (GUI or Web client)?<p>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.<p>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 astronaut, but meh, I might be biased).<p>MVC seems to suit widgets level better as opposed to the architecture pattern for a Rich UI app.

A similar discussion about Cocoa MVC: <a href="http://stackoverflow.com/questions/353646/design-patterns-for-apples-cocoa-frameworks-mvc-mvp-passive-view-where-is" rel="nofollow">http://stackoverflow.com/questions/353646/design-patterns-fo...</a><p>The point is that it gets you to think about design patterns that the framework writers intended.<p>Anybody know if the rails MVC pattern was based on Cocoa? I know a lot of Rails devs who are also Cocoa/Touch devs.