10 ms·

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

• jshen 14y ago
  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.
  • deleted 14y ago
    [deleted]
  • blahbap 14y ago
    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.
    • blowski 14y ago
      Users are not necessarily human - they can be search engines, API consumers, etc.
      • blahbap 14y ago
        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."
        • jshen 14y ago
          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
          • blahbap 14y ago
            "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 http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf And you are not a human user, you are an engineer.
            • jshen 14y ago
              You keep using an appeal to authority, and I still see no value in the distinction. I am most certainly a human user.
              • alexro 14y ago
                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)
                • jshen 14y ago
                  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".
    • jcarreiro 14y ago
      > JSON and RSS are just different methods for representing data to be communicated to other systems. We call those, "views".
      • Androsynth 14y ago
        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.
        • TylerE 14y ago
          Bullshit. Please show me your Rails-or-similar app that's doing INPUT parsing in the view (embedded JS doesn't count)
          • Androsynth 14y ago
            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.
            • melvinmt 14y ago
              It's the browser who renders anchor tags clickable - if you click on a link in a RSS reader you also get routed.
            • randomdata 14y ago
              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?
              • Androsynth 14y ago
                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...
    • deleted 14y ago
      [deleted]
    • jshen 14y ago
      "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.
      • blahbap 14y ago
        The purpose of the distinction is to prevent even more confusion about what MVC means.
        • jshen 14y ago
          I find the distinction more confusing, and I don't see the value.
    • FuzzyDunlop 14y ago
      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.
      • jshen 14y ago
        rails is moving towards a "view" based approach. Here is one of the up and coming libraries. https://github.com/rails/jbuilder/ https://github.com/rails/jbuilder/ It looks a lot like a view file :)
    • sophacles 14y ago
      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.
      • blahbap 14y ago
        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.
        • HeyImAlex 14y ago
          > 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....
          • Androsynth 14y ago
            no, those output types dont map back to the controller, they are not views.
            • alttab 14y ago
              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.
        • sophacles 14y ago
          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!
    • corford 14y ago
      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).
      • deleted 14y ago
        [deleted]
      • blahbap 14y ago
        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).
      • jrgnsd 14y ago
        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.
• mikeryan 14y ago
  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.
• drivingmenuts 14y ago
  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.
  • Ygg2 14y ago
    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.
• einhverfr 14y ago
  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.