Live data from Hacker News

Rails is not MVC

andrzejonsoftware.blogspot.com

21–30 of 49 posts

Re: Rails is not MVC

#21

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…

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.

Re: Rails is not MVC

#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 like a view to me - it's the thing you're viewing!

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.

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.

Re: Rails is not MVC

#24
post #4

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

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

Re: Rails is not MVC

#25
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…

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"?

Re: Rails is not MVC

#26
OP here.

There's one more reason why I want to clarify the situation with terminology.

Apart from being a Rails developer and running a Rails company I also teach Ruby on Rails at a university.

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.

It doesn't help me that when they go to any Rails website there's information that Rails is MVC, which is not.

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.

Re: Rails is not MVC

#27
post #4

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

> 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…

> encourage more thinking outside the box.

think outside the box ? how about...."controller function" !

There now I've blown your mind.

Who says controllers have to be classes ? Again in GOF days, it was all smalltalk/C++, everything was a class. Not the case with what we use today. A "module of functions" is not terribly different.

Re: Rails is not MVC

#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 validity. But the domain could also be something that is not stateful per se, like interfacing with hardware.

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.

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.

Re: Rails is not MVC

#29
post #27

Earlier quoted context omitted.

> 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…

> encourage more thinking outside the box. think outside the box ? how about...."controller function" ! There now I've blown your mind. Who says controllers have to be classes ? Again in GOF days, it was all smalltalk/C++, everything was a class. Not the case with what we use today. A "module of functions" is not terribly different.

You are preaching to the choir. :-)

Re: Rails is not MVC

#30

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

Post reply on HN