Hacker News Reader

Comment by jaaron | Hacker News Reader

MVC, more than other design patterns, is horribly abused. Developers should keep in mind its GUI roots. Here's my "is it MVC?" litmus test:

How much of my code survives if I drastically change the view?

For example, if I want to switch to a new desktop, web or text console interface, can I reuse much of the application? Of course, architecture changes this significantly (particularly web architecture), but still, if I cannot swap out the view, then I'm losing out on one of the significant advantages of an MVC architecture. One way to make sure this works is to start with 2 views from the beginning - the view you're actually going to ship, and a headless view for tests.

View on HN

I remember the first time I heard of MVC in a web context, almost 15 years ago. (ffs). I did what I normally did and looked it up and totally struggled with how an approach that seemed to be focused on device input would map to a web framework. After working with a few "MVC" frameworks I completely gave up on mapping what they called MVC to what I thought MVC was (which was based on a pretty old definition at that point). When I finally started using Rails I finally found a framework where at least the M,V&C were pretty clearly defined, though not in the context I thought they should be according to the pattern.

Anyway long story short. I don't think the pattern is abused anywhere near as much as the term as been.

my rails apps pass this test with flying colors. Nearly all of my end points have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and 1 for rss/atom.

JSON and RSS views don't make sense - in MVC, views are visual representations of data (the model). Views are how the user percieves the application. JSON and RSS are just different methods for representing data to be communicated to other systems.

Users are not necessarily human - they can be search engines, API consumers, etc.

In the context of MVC, a user is a human being - describing JSON and RSS services as "views" totally misses the point.

Quote from the inventor of MVC, Trygve Reenskaug:

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

I'm a human user and I have a mental model of the json and rss apis I consume via code I write. I notice that he didn't say visual as you did earlier

"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter."

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

And you are not a human user, you are an engineer.

You keep using an appeal to authority, and I still see no value in the distinction.

I am most certainly a human user.

If you're so keep on giving a different meaning to already defined standard why not use some other abbreviation, say MRC (R for Representation)

MVC is not a standard. I also don't find it useful to have different names for ideas that are effectively the same with some distinction that doesn't seem to make a difference.

Maybe there is some significant difference, but you haven't outlined one other than "it's not what person X says MVC means".

> JSON and RSS are just different methods for representing data to be communicated to other systems.

We call those, "views".

In an MVC, the views are used both for output of the model and to map input back to the controllers. Without the input, its not part of the MVC pattern.

Bullshit. Please show me your Rails-or-similar app that's doing INPUT parsing in the view (embedded JS doesn't count)

When you click a link on a web page, it gets routed to a controller action. Thats done because the link was generated with the url: example.com/controller/action. Its not about parsing input, its about routing.

It's the browser who renders anchor tags clickable - if you click on a link in a RSS reader you also get routed.

HATOES says that your XML/JSON/whatever needs to have those same links. What is the difference between an <a href=""> link in HTML and a { action_url: "" } property in JSON?

Nothing I suppose. I don't think that html vs json was what MVC's[1] creators had in mind for it, but if the json is rendered in such a way that it has links pointing back to the controller, it is a view.

[1] Although were talking about Model 2 here, so thats irrelevant. Come to think of it, this whole discussion is pointless: we're arguing about whether views in a Model 2 architecture are proper MVC views...

I disagree. Yes, MVC provides a pattern that allows views to be input to the user, but if it doesn't make sense for your app, it's perfectly fine to make the view "read-only" and still abide by the spirit of MVC.

If you're claiming that regular HTML views are compliant with MVC because they have HTML links, one can argue that some RSS readers convert the reference links from the RSS feed to actual HTML links that you can use to navigate to the individual RSS item. How is that different than a regular HTML view with links?

"views are visual representations of data"

I see no purpose for this distinction. A view is an output representation of the model data.

Given the challenge, "How much of my code survives if I drastically change the view?", I think json and rss make perfect sense. They are drastically different output representations of the data.

The purpose of the distinction is to prevent even more confusion about what MVC means.

I find the distinction more confusing, and I don't see the value.

HTML is also one of those different methods. It just so happens that the browser renders it instead of spitting out the raw text.

That said, non-HTML output bypasses the view entirely in Rails (it makes sense to), so it can equally be the case that the distinction is correct.

rails is moving towards a "view" based approach. Here is one of the up and coming libraries.

https://github.com/rails/jbuilder/

It looks a lot like a view file :)

So it's only a view when you write all your code to push bits to the monitor yourself. Outputting using libraries that convert formats like html (-> browser -> os/driver -> screen) aren't views. Got it.

Let me give you an example. In your model, you have represented the salary of an employee as an integer. In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library). The tools you use to build the view are not relevant.

> In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library)

as JSON encoded output, as XML....

no, those output types dont map back to the controller, they are not views.

Restful Apis often times can return JSON with key value pairs for subsequent actions in the form of name: URL. While you can't click on JSON, it's a "view" for the consumer application because it can follow back into the controller. The distinction is that a view doesn't necessarily need to be a human reading a screen, and can most certainly be another application.

Ohhhh, I see now. So some data formats that render to screen through external software are views, like html, json, generated javscript or xml if they go through jQueryUI or charting libraries, but if it goes through other external software like RSS readers, or non html, json, or javscript formats, before making it to the screen, it is no longer a view. Thanks for the clarification!

jQuery UI and the charting lib are not external software, they are part of your system (application). By your logic, every possible digital representation of the model is a view because you can always dig up some tool somewhere to visualize your model. "Look, this floppy disk is a view in my MVC application, just insert it into the Commodore 64 and enter 'LOAD I_LOVE_MVC,8' "

That's not inconsistent. A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant.

This whole discussion is about MVC. In order to argue about MVC we should have a common understanding of the principles of MVC. MVC was invented by Trygve Reenskaug. His definition of MVC is both consistent and readily accessible. Therefore I have repeatedly referred to him for a definition of the components of MVC. Surprisingly, many of the posters don't seem to regard the inventor of MVC as much of an authority on MVC, preferring instead to come up with their own definitions.

You have just provided a new definition of a view:

"A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant"

If this definition suits your application, good for you. But you are no longer talking about MVC.

Given the choice between admitting that one's comment wasn't well researched, and wasting thousands of eyeball hours with whatever-it-takes rationalizations about why one's comment actually was rather well thought out, most of us make the correct choice.

Unfortunately, the wrong choice comprises nearly half of comments made. You were obviously right the first time - let it lie :)

If you take Reenskaug's original MVC, and replace the human with an external system, what changes in the M-V-C part of the architecture? Nothing. Not a jot. It's identical, or can be. What's important here isn't the original intent of the architecture, it's what we can use it for. My butterknife isn't any less a butterknife because I'm cutting an apple with it, is it?

The problem here is that Reenskaug explicitly abrogated the authority you're appealing to. He recognised that MVC as originally posed was problematic and incomplete, and invited others to refine it via a pattern language, making MVC a metadefinition. At this point in history, you simply can't point at "MVC" and say that the original definition is canonical.

If you're still going to appeal to the original definition, the View still isn't a visual representation. That's the Editor. Everyone seems to forget about that bit. If you exclude the Editor, we're no longer in Reenskaug-MVC, so even if they weren't in the first place, machine representations would be ok. If you include it, your objection to JSON and RSS representations per se falls apart, because they can be perfectly valid technical details of the Editor layer under control of the View.

   If this definition suits your application, good for you. But you are no longer talking about MVC.

Yes, I am. I'm just not talking about your definition of MVC, which is needlessly proscriptive.

Not saying I disagree with you but then where exactly would the JSON and RSS output methods go in an MVC framework, if not in a view i.e. how would a different system or user consume/access their output? Directly from a controller? Would love to know your thoughts as I've always found MVC a difficult conceptual approach to grok when applying it to web apps (lots of code never seems to have an obvious M, V or C home).

Services that provide data as JSON and RSS are not part of MVC at all. Even if you use MVC for your application, not _every_ part of your application has to fit into MVC. You use MVC only for the part of your application that communicates with the user. Other parts of your application, like external APIs, should not be crammed into any of your MVC components. A service that provides RSS or JSON on request would simply fetch data in a database and send it along, bypassing all your models, views and controller entirely. (Note that the database is not considered a part of MVC).

I'm not 100% sure where it fits in, but I tend to write have a Formatter service that is used by the controller to pass the model to the correct view.

The Formatter inspects the Request to determine what format it should be (html, json, xml, etc.), and returns the correct View to the Controller, which then passes the Model to that View.

I agree with this.

The way we chose to do things in LedgerSMB (starting with the new code in 1.3) is to adopt a sort of untraditional MVC. The view has to represent the model and vice versa (information present in the model thats not in the view is never used, information present in the view but not in the model is always discarded).

However, the controller scripts are agnostic of this structure. They just glue these together and process operations. Therefore depending on the changes to the view, you may or may not have to change the model, but you should not have to change the controller unless you want to change what a button does. Similarly for reports, you can change these to your heart's content and no underlying changes are needed at all.

We've run into a lot of resistance from folks more used to traditional MVC stuff because the controller only needs to know what it minimally needs to know (and usually this is virtually nothing). Since everything is hash refs passed around....

But in the end the approach works, and specifically because we try hard to keep things fairly abstracted and loosely coupled within the application.

Maybe I'm doing it wrong, but I've always thought Controllers were supposed to be dumb and Models were supposed to be smart.

That is, a model encompasses extracting the knowledge and turning into something that the controller passes to a view or another model, but is not processed much (if any) during the transfer. At most, it might be combined with data from other models into an uber-record that is passed to the view.

Yes ideally, controllers don't do anything than react to events, change model and update the view. In practice Controllers can get quite fat. It's a bit like Thin client/Thick Client in Client/Server environment.

Reply on news.ycombinator.com