Live data from Hacker News

Rails is not MVC

andrzejonsoftware.blogspot.com

11–20 of 49 posts

Re: Rails is not MVC

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

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.

Re: Rails is not MVC

#12
A similar discussion about Cocoa MVC: http://stackoverflow.com/questions/353646/design-patterns-fo...

The point is that it gets you to think about design patterns that the framework writers intended.

Anybody know if the rails MVC pattern was based on Cocoa? I know a lot of Rails devs who are also Cocoa/Touch devs.

Re: Rails is not MVC

#13
post #2

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. Also, as far as I recall, the MVC pattern does not require communication between the models and the views, although it certainly allows it. Looking at it from another perspective, MVC is a huge buzzword nowadays. It's simply not worth it to be…

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.

MVC - MVC is separated, Models can notify Views.

I don't think the ability for models to directly notify views can be considered a strict requirement. NextStep/Cocoa followed the MVC pattern closely without having this ability for a long time. (It was added as "key-value observing" in Mac OS X 10.3.)

Without direct notifications from models to views, it's up to the controllers to notify each other of model updates. Personally I find this pattern preferable to having models doing uninhibited notification broadcasting on their own.

Re: Rails is not MVC

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

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

Re: Rails is not MVC

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

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.

Re: Rails is not MVC

#16
post #14
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.

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

TFA

> In short, we're talking about MVC when a model can notify (through the Observer pattern) the views about the changes. It's not possible in a classical Rails app (it's possible when you use WebSockets, Pusher or a similar technology, but it's not so popular yet.). MVC was popular in desktop apps.

MTV isn't really Web nature. You change the database schema, and the browser client automatically refreshes? I don't think it's really useful. An ad-hoc solution would be better.

Re: Rails is not MVC

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

Re: Rails is not MVC

#18
post #2

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. Also, as far as I recall, the MVC pattern does not require communication between the models and the views, although it certainly allows it. Looking at it from another perspective, MVC is a huge buzzword nowadays. It's simply not worth it to be…

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.

Model1 started by everybody (including Servlet, pre-JSP) Model2 started by Servlet + JSP.

Re: Rails is not MVC

#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 astronaut, but meh, I might be biased).

MVC seems to suit widgets level better as opposed to the architecture pattern for a Rich UI app.

Post reply on HN