Hacker News Reader

Comment by icebraining | Hacker News Reader

I'm certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it.

No, that's just with the bastardized version of MVC popularized by Rails et all, which treat the views as little more than templates.

In the original MVC papers from Smalltalk, the views did actually send messages updating the model:

   A view is attached to its model (or model part) and gets the data
  necessary for the presentation from the model by asking questions.
  It may also update the model by sending appropriate messages.
  All these questions and messages have to be in the terminology
  of the model, the view will therefore have to know the semantics
  of the attributes of the model it represents.

http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

View on HN

Rails didn't bastardize MVC, users of Rails bastardized MVC. Over the years we've seen the progressions of fat controllers to skinny controllers and fat models. Now, we're seeing the progression of using models only for responsibilities related to persisting the object. This leads to extracting additional domain logic into Presenters, Value, Service objects, etc.

Avdi Grimm has a great book about this called Objects on Rails[1] and Bryan Helmkamp from Code Climate has a good introductory blog post on it as well[2].

Rails implementation of MVC is perfectly fine. It's when people lean on MVC for everything without applying "classic" Object-Oriented design. That's when things become a mess.

1 - http://objectsonrails.com/

2 - http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decomp...

The decomposition of ActiveRecord Object is not bad. I don't like class like UserAuthentication and AbandonedTrialQuery. I would rather have something like.

#app/models/user/query.rb

class User

  module Scopes

    #my scopes.

  end

end

Everyone has their own preference for implementing object oriented design which will help push things forward. The important part is that people are thinking about object oriented design more than ever before.

As an aside on terminology, why do we use the terms "skinny" and "fat"? Shouldn't it be "short" and "tall" since code is represented vertically?

I imagine the words as analogies to people and their ease of movement. Fat (“bloated”) components are hard to work with and develop, in the same way a fat person has trouble running from point to point. On the other hand, skinny components are easy to work with because there is little to comprehend, the same way that skinny (“lean”) people will run more quickly and easily.

Because that's the title of this blog post: http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat...

The only times 'fat' and 'skinny' are mentioned in the title.

because fatness is ammount of business logic, not ammount of lines of code. a model with 150 data fields can be a skinny model.

All programming language terminology gets blurrier the wider the usage of the term becomes. Right now, if you keep your eye out, you can see this is happening to the term "coroutine"; it's currently mutating from it's programming language research meaning [1] to something indistinguishable from "lightweight thread", or indeed possibly even indistinguishable from "thread".

"MVC" as a meaningful term has been dead for at least 5 years.

[1]: http://en.wikipedia.org/wiki/Coroutine

Rails started out as a "the database is stupid, it is just storage" and "models are just object wrappers over your stupid database" as defining characteristics. And it has always had this weird notion that everything has to go through controllers. So it certainly did bastardize MVC, and the guy who came up with MVC has even pointed this out (not specifically about rails I don't think, but about the plethora of faux-MVC frameworks that exist now).

Most criticism of MVC and frameworks can be summarized as:

"I don't understand MVC, this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own. So I'll just stuff my spaghetti style code somewhere, and bitch about MVC and/or the framework being insufficient/dead/shit."

It's the ultimate expression of a bad craftsman blaming his tools, and it's endemic in web development.

I've lost count of how many times I've had to argue that the View binds (loosely put, for View <-> Model interaction) directly to the Model. The Controller only enters the chain if the operation is more complex, i.e. it is a composite operation.

That said - the Controller is the only place that is left if the code isn't interface or datastorage specific, so naturally it's the first place to get bloated. But that's fine, you just have to take care of that when you can, by abstracting common functionality and/or move it out in a library.

"this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own"

Funny, because too me that seems like the whole point of MVC: To have a one-size-fits-all "architecture" to shoe-horn your business logic into.

But then again I never really understood the point of MVC. It seems like a somewhat nice fit for GUI applications, but that doesn't mean you should use it for everything. The real takeaway is to decouple and abstract to the point that makes sense. Not too much and not too little.

> it's endemic in web development

Important word here: 'web'. If you move that word all ror puritanism falls apart. For example imagine multi-protocol MVC. In that sense javascript is really part of view and it can 'pass messages' to model using ajax.

> No, that's just with the bastardized version of MVC popularized by Rails et all, which treat the views as little more than templates.

While Rails did use this and make it popular, it's older than that: http://en.wikipedia.org/wiki/Model_2

A nice way of putting it. Somewhere along the line of web/http systems views became templates -- while an MVC "view" really is (some) logic+rendering -- not "just" rendering.

I'm not sure if rails is the first offender here -- php (and asp, jsp etc) makes it so easy to drop a ton of complexity on your lower extremities that it becomes necessary to "ward off" the part that actually does templating from the rest of your code -- which, if it's all old school php -- isn't terribly easy to do -- or at least isn't trivial to make "obvious" in your code.

If you fail to maintain a part of your code as template-php, and mix it up with your logic, your nicely structured application quickly becomes a mess (this is what old php codebases I've looked at looks like -- and has left me a a little resentful against the entire language. Probably more than php deserves).

php is not a framework. How many people use bare ruby , bare python or bare java to code webpages ? ( and by the way JSP can be a mess too , so it's not about the language,it's about the brain behind the desk ). Rails , Django and others give devs MVC for free , not PHP, not Ruby , not Python.

Actually, a good code smell / architecture smell in a Rails app is if any given controller method is over 10-15 lines (And even that is on the large side IMHO). For example, I believe Code Climate specifically penalizes your score for long methods in controllers.

I write plenty of Rails apps that have thin controllers and fat models. Class methods / static methods on models can help encapsulate business logic in any language's MVC frameworks, as well as liberal use of the Tell Don't Ask pattern.

Nice, clean, and crisp.

Interesting link. Do you know the original context? I’d be the first to agree that a lot of back-end web frameworks have wildly distorted the original idea of MVC, and in many cases completely missed the point of why it was useful. However this is the first time I’ve seen anything from the original Smalltalk days that presented the relationships like this, with views affecting models and a controller implicitly being related to multiple views.

The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context which is what Rails and many other frameworks have done. Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side.

Rails and the other MVC frameworks don't just focus on the client-side, however. They are also deeply involved with the database and everything in between so a pure implementation of MVC is out of their reach. On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. Once we break those apart you can have a Smalltalk style MVC implementation on the client-side and organize your "back-end" code to your hearts desire or use a back-end specifc framework to guide you there.

Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side.

There is little need to debate that point. Doing MVC-style architecture on the browser side works just fine. One of my long-term projects is a relatively large web application that uses something very close to the original MVC idea, with a central model that holds all the state and then a few dozen view-controller pairs that handle all the ways of interacting with it. This architecture has served me well for several years now, and the design has proven to be very easy to maintain and adapt to changing requirements. (In practice I add a fourth type of component in the web context, a “store” that is responsible for communicating with the server, and I define a small number of additional relationships to go with it because it doesn’t fit into any of the other three categories. Even then, the store acts somewhat like a view-controller pair for most purposes, and the cases where it doesn’t are mostly things I might do differently with the wisdom of hindsight.)

On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side.

I’m not sure why we need any distinction between them. Ultimately, we’re just writing a distributed application, which happens to run using something like HTTP as a communications protocol in this case. All the usual concepts about maintaining state and actions that have side effects apply, and all the usual arguments about separating such concerns apply. What makes you think we can’t use these ideas already today?

The original context was for building interactive GUIs. I think you're right that web frameworks' concept of MVC is different than the original context because of the request/response cycle of HTTP. However, understanding the original ideas of MVC has helped me a ton even when writing backend code for the web.

Trygve Reenskaug actually setup a web page to explain how MVC was originally conceived [1]. My main take-away was that models correspond with the user's mental model while using the application: "The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly." The most important (IMO) implication of this is that your models aren't limited to data that exists in a database, which is a mistake that I see a lot of web developers make.

http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Sorry, I wasn’t clear. I’m familiar with the original GUI-based work, or at least I thought I was.

However, this is the first time I’ve seen any material from those early days that suggested having the view affect the model, as opposed to being a mere observer, passive or otherwise, and having controllers responsible for all changes of state.

It’s also the first time I’ve seen an early source suggest having one controller deal with multiple views, as opposed to possibly having multiple controller-view pairs associated with the same underlying data but with each view having its own associated controller. I’ve seen variations with views and controllers nested and using some form of delegation/bubbling if the presentation is complicated, but that’s not quite the same thing.

The only original papers I’d seen previously, even those that I thought included Reenskaug as an author, already had the characteristic triangle arrangement with one-way traffic from the model to the view and with a 1:1 view:controller relationship, so I was interested to know the origin of the paper that icebraining linked to. Your link answers that question, so thanks for that.

In the original (ST and desktop GUI centric) MVC, controller and view were essentially interfaces. View is something that can draw window on screen and controller is something that processes/redistributes events from input devices. On the other hand model is simply something that can be hooked up to that, ie. stores state accessible by views and controllers and notifies views of state changes.

The idea of view directly modifying models comes from fact that in many cases there was class named FooView, that acted both as view and controller (which generally makes sense because the low level GUI logic is same for both). Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar).

Sure, as an implementation detail that might be how things are done, but that’s different from conceptually having the view responsible for changes of the model’s state, no?

Also models represented not only the actual data but also various parts of GUI state itself (eg. position of scrollbar).

I think everyone who tries MVC probably comes up against the “Where does view metadata go?” question sooner or later. FWIW, I think treating that kind of transient state as part of the model is unwise.

If it’s metadata that applies to one specific view, as with your scrollbar example, it can live on the view. The corresponding controller can then send suitable commands to the view to update it in response to user actions, and the model is completely unaffected.

If it’s metadata that is shared among multiple views, such as which element of a system has a focus/active state or something like a clipboard/kill ring, then I prefer to introduce a completely separate component. Each affected view will observe that metadata component in the same way it observes the model, and therefore each corresponding controller can update that metadata component in response to a user action on its view and all affected views will react. Often, the metadata component may itself also observe the real model, so that for example if an item with focus is deleted from the model it will also cease to be recorded as the current selection in the metadata for any views.

This approach isn’t quite as tidy as pure MVC, but it does maintain clear responsibilities and collaborations between all of the components involved. In particular, it maintains the general design principles of MVC, and it does prevent anything that isn’t really persistent state or related business logic from polluting the model.

In addition to the original stuff on MVC, the newer stuff on DCI[1](Data, Context and Interaction) is also illuminating wrt one way to progress with software architecture for interactive/event driven applications.

[1] https://en.wikipedia.org/wiki/Data,_Context,_and_Interaction

The original flaw, if you ask me, is the naming. WTF is a model? WTF is a controller? WTF is a view? You can (and I have) explained this to a newbie for an hour and they still won't get it.

They may as well have named it 123. At least that wouldn't make you guess at what the naming signifies.

Well obviously the nuance is going to be lost on someone who hasn't actually programmed the type of system the pattern refers to. There's no way for someone to grok it without a mental model of what the system needs to accomplish. However with that experience it's really not that hard to understand.

I disagree. That's not obvious. It's relatively easy to explain parallelism, concurrency, recursion, currying, idempotency, the visitor pattern, etc. etc. This is different. MVC names are really annoying and poorly chosen. Every time I think of the pattern, I have to make an association between each word of the pattern and its meaning.

For example, the Model of MVC consists of business logic and sometimes what people refer to as... models. The business logic controls how models are modified. The Controller doesn't. The Controller controls very little when the system is correctly architect-ed, especially when you have multiple UIs.

Really, the View is the only one without ambiguity. But even so, I still have to google from time to time to remember who is allowed to know about who and who notifies who of what...

A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator".

Edit: Having thought about it more, I decided to change the word Presentation to View in my "better name" suggestion.

> A better name, and this is literally off the top of my head, would be "Business Layer, View and Event Translator".

That's not far off the original meaning AFAIK. It used to be called MVCU - model-view-controller-user. The "model" is the idea of the data as it exists in the users mind, the view is how the system presents it, and the controller works with what the user "do" with the model through the view.

It gets confused if you don't realize there are two data models: the "data" model - how the data is modelled in the abstract (and confusingly, internally in the program/database) -- that is distinct from the model in MVC. So the original MVC "model" is closer to "domain model" than to "data model".

Now, in the dark 90s, when everyone had forgotten that users existed, something that no-one would realize until "agile" emerged and surprised everyone, these two "models" got mixed up -- and no one was able to understand this MVC thing ;-)

I think it can be explained pretty easily, even if necessarily generalizing.

Model is a representation of the data of your domain and behavior imminently related to this data. I.e. what is "user" and what it means to "create a user"? What does it mean to "find most active users"? The name is because it "models" the domain by representing it as an abstract interface.

Controller is a representation of the rules of when and which models are invoked and which actions are performed. I.e. when we would "create a user"? When we would need to "find most active users"? The name is because it "controls" the models, telling them what to do.

View is how the information presented to the end consumer and how the consumer interacts with it. I.e. what it means to actually show "most active users" to the end consumer? The name is because end consumer "views" it.

Of course, this explanation without actual experience of how such systems are designed and behave does not make a newbie magically able to design complex systems flawlessly. No amount of name changing would. But explaining how this approach works doesn't seem that hard to me.

Let's not confuse activerecord with MVC though. Rails suffers beacuse of AR not because of MVC.

Isn't that a presentation model? Where the view gets it's own model so you can swap out different UI implementations.

I am amazed at how one web framework managed to completely redefine a long standing pattern in such a short time. MVC is quite old, and well established, and was even used in web development well before rails came along. But now suddenly 99% of people think MVC means a rails style mess.

yeah, that's really relevant. smalltalk, 1979!

Said the inventor of rails... (...?)

You are as funny as ignorant.

DHH called a Smalltalk book one of the best programming books ever: http://37signals.com/svn/posts/3375-the-five-programming-boo...

So I'll step out on a limb and say that it strongly influence(d/s) the design of Rails

Reply on news.ycombinator.com