2

I recently read an answer regarding MVC and web development, mostly about how it was originally designed for older systems and has since been applied poorly in web development. That being said, I'm sure every pattern has by now been used poorly in web development. But I'd still like to make sure that I don't make the same mistakes in applying this pattern to web development, leading myself and potentially my team into having the same bad experience with MVC.

We now deal with an obscene web-mvc hybrid that, with its awful buzzword status, ill definition, and having semi-illiterate-programmers as a target demographic, makes a really bad publicity to software patterns in general.

MVC, thus, became separation of concerns distilled for people who don't really want to think too much about it.

As someone learning about MVC and considering using it in a web application, I'd like to know from an objective perspective how the MVC pattern should be applied to web development.

It's occurred to me that web development, having pre-existing methods for rendering content via the DOM, and with JavaScript being a loosely typed language, MVC probably relates very differently to web development than it does to older systems used when it was first popularized.

Fundamentally speaking, how does the usage of the MVC pattern's (proper) usage in web development differ from its usage in a non-web environment, with strictly typed languages and no DOM and browser rules for easy GUI rendering and alteration? In other words, does the fact that we're ususing

  • JavaScript, a loosely typed and very different language from the ones used when the MVC pattern was designed

  • and use the DOM + CSS, a predefined simplified method of rendering content, whereas before web development, applications used their own rendering engines or rendering libraries to display content, perhaps making the MVC pattern more necessary

change the way we should define and use the MVC pattern in a web development environment? Are there any fundamental differences in the original usage of MVC in a non web environment and using MVC in web development?

Community
  • 1
J.Todd
  • 3,833
  • 5
  • 22
  • 27
  • 3
    You're quoting a guy that had a bad experience, for whatever reason, so now he's down on all things MVC. Doesn't mean it's a bad technology. – Robert Harvey Oct 21 '15 at 04:51
  • Yeah, I think this is more focused now. –  Oct 21 '15 at 10:33
  • @RobertHarvey but I wouldn't totally discredit that bad experience. It makes sense for me to look deeper into the topic before I end up making the same mistake he's referencing. – J.Todd Oct 21 '15 at 10:46
  • 1
    At the risk of going all philosophical, can you define what a "non biased point of view" means? – Cerad Oct 21 '15 at 12:49
  • 2
    To clear up a misconception: MVC was originally developed for use with Smalltalk, which is a dynamic language that is probably more similar to javascript than the languages you appear to assume it came from. – Jules Oct 21 '15 at 17:17
  • @Jules oh neat - thanks for that info. I had known JS was just a very different language from what was popular, and had thus assumed that there hadn't been anything very similar. – J.Todd Oct 21 '15 at 19:34
  • 1
    @JonathanTodd [This answer](http://programmers.stackexchange.com/a/127638/57138) further down in that question thread references the original work on MVC; you might check out the web-page he links to for more of the history. I found it interesting. – paul Oct 21 '15 at 20:33

3 Answers3

3

The typing or the language makes no impact whatsoever, so ignore that.

The Model is the same, as its the holder for all data that is passed on for display.

There's difference in the View - where the original constructed a GUI that was persistent, the Web equivalent constructs a GUI each time a request is made from the client browser. However, both are doing the same kind of work (roughly) - constructing a view, its just that one is persistent and the other transient. Operations on one directly call the controller to manipulate elements, whereas the other has a browser as a 'proxy' for this, only calling the controller when links are clicked that require a refreshed view.

This suggests the Controller part is the main difference - whereas the original used this to route messages to event handlers to manipulate the GUI elements, the web version is more concerned with routing the request for a view.

So I would say there's little difference from a conceptual point of view, though big differences in implementation, but then you could say this about a MVC system created using C++ MFC and another created using Swift and Cocoa for example. I imagine you could create a MVC desktop system that recreated the GUI display every time a link was pressed (and could say this happens anyway, if you click a button that pops up a dialog, its creating a brand new view for you). Similarly, persistence of data is the same - lots of thick GUIs write directly to a database, and although they don't fetch state for every request, using session state or not isn't exactly a fundamental aspect of MVC.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • Could you please also explain MVC for web development which doesn't use page refreshes for content updates. I'm confused by the way you explain it partly because I think of page refreshes as bad for user experience. Modern web applications that I'm interestedin use JSON, AJAX, websocket, RTC, etc to dynamically grab content, and in that case it seems that the server would not be part of the MVC pattern. It seens to me that the MVC pattern is designed to be a fully client side pattern... – J.Todd Oct 21 '15 at 16:44
  • I can sort of see how early web applications would use a hybrid version of MVC to handle http requests / content updates but thats already an old and dying (an opinion, but probably an accurate one within the next few years) style of web development. I'm really interested in the kind of web application which doesn't deal with page refreshes or changes, but rather takes a single page and updates content on it dynamically. – J.Todd Oct 21 '15 at 17:06
  • What's the difference? A single-page app still makes requests of the web server which returns either data or html, this is then displayed in the browser with only a partial page refresh. The tech behind the scenes is still the same, just the browser is a bit more clever with its client-side javascript that dynamically updates the html display. (though websockets does change the tech, the response data sent to the browser is still the same as you'd be getting in a normal request-response). – gbjbaanb Oct 22 '15 at 07:35
  • Maybe you'd be better off forgetting MVC and thinking of n-tier or microservice-stye architectures instead I always thought MVC was a poor version of n-tier anyway. – gbjbaanb Oct 22 '15 at 07:36
  • Hmm.. Ok I have some studying to do to figure this all out it seems. Thanks for the advice and info – J.Todd Oct 22 '15 at 12:59
  • This answer misses an important part of original MVC, which is that the view directly monitors the model for changes using the Observer pattern, thus allowing two views to show the same data and remain synchronised when the data is changed. This aspect of the pattern is usually entirely missing from web-mvc applications. – Jules Oct 23 '15 at 08:18
2

The original use of MVC in desktop GUI frameworks is fundamentally different from server-side MVC frameworks like RoR or ASP.Net MVC. The web MVC architecture is inspired by the original MVC (hence the name) but it is not the same pattern, since the request-response or the web is fundamentally different from an interactive desktop GUI. If you try to think of of it as the same pattern you will just get confused (as the guy you are quoting clearly is), so better to think of it as two different patterns for different architectures which just share the same name.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • The idea of MVC being a server side feamework is confusing to me. When I develop a web application, I don't refresh the page ever, but rather use JSON or a socket to load content and information dynamically. So would the server that responds to a socket message be part of my MVC pattern? I don't see how the server would be part of the pattern. – J.Todd Oct 21 '15 at 16:38
  • 1
    @JonathanTodd: Server-side MVC and client-side MVC are again two different things. – JacquesB Oct 21 '15 at 21:24
0

Okay, I'll bite, but a small disclaimer: I don't have any sources backing me up (at least that I can link to, they might be out there) and this is written purely from my understanding/interpretation of the original intentions of MVC which might very well not be correct.

Originally MVC made sense because heavily managed event-driven GUI engines (such as a window manager or DOM) didn't exist. You had a model, a view (monitor), and a controller (keyboard). Now, whenever something was triggered on your input device (keyboard) you needed to alter your model and subsequently update the view. This was the usual UI paradigm at this point in time - then along came window managers.

Window managers abstracted the input device away some, by tying the view and the controller together for you. You no longer received a "keyboard y was pressed"-event but rather a "textbox1 had an y applied to it"-event, or in the case of a mouse it was no longer "mouse clicked at point(400, 500)", but "mouse clicked on top of button1". The UI was now interactive, and I'm sure most Window managers use pure MVC under the hood and keep a model of where on the screen button1 is and which element has focus etc. etc.

Fast forward; people kept using the word "MVC" in interactive GUI programming, but it sort of lost its meaning. I remember when I was a student and we learned about MVC, and I tried to somehow fit the pattern onto java swing. I never fully understood why we had to do that, as it made absolutely no sense ... What was the input now? Why should I separate the buttons appearance from its input-options when both of these was already tied together for me in the jButton class? This is where I think a lot of confusion comes from...

Now, another small and popular way of programming a UI is leveraging HTTP and the world wide web. Server-side MVC has been reborn with a ton of frameworks popping up embracing the pattern in its original intention. Something happens as an input (a HTTP request) which alters the model and finally updates the view (by doing a response of some html).

All well and good. We got Interactive GUIs using window managers (like WPF, JavaFX, Qt, etc) and we got non-interactive GUIs (like HTTP or embedded MMIs).

So which of these is client-side MVC on the web? I'd say they look a lot more like interactive GUIs than non-interactive ones. You got a DOM which handles both appearance and behaviours and you got a closely tied view/controller (at least according to MVCs original definition). In my opinion this leads to the same conclusion as for desktop programming; original MVC just doesn't fit, and something like MVP (which a lot of 'MVC-implementations' actually look a lot like) or MVVM makes more sense.

So, back to your original questions:

In other words, does the fact that we're ususing

JavaScript, a loosely typed and very different language from the ones used when the MVC pattern was designed

and use the DOM + CSS, a predefined simplified method of rendering content, whereas before web development, applications used their own rendering engines or rendering libraries to display content, perhaps making the MVC pattern more necessary

change the way we should define and use the MVC pattern in a web development environment? Are there any fundamental differences in the original usage of MVC in a non web environment and using MVC in web development?

IMHO, yes. There's fundamental differences in the original usage of MVC in a non web environment and using MVC in web development, and we probably should change the way we define it, but at this point I think it's too late. Let the buzzer's keep saying MVC, while the rest of us refer to "Original MVC" or "Buzzword MVC" :)

cwap
  • 347
  • 1
  • 8
  • 1
    Sorry this is just incorrect. View and controller in MVC never referred to keyboard or monitor. MVC was from the beginning an OO pattern which means all three parts were software objects interacting. – JacquesB Oct 21 '15 at 15:53
  • Thanks! Regardless of the above comment (which may be correct), to me, being able to learn from your lifetime of experience is a real privilege. My generation.. Being able to access answers which draw from entire careers of experience, for free, within minutes of asking a question.. We have no excuse not to go 10x further than any generation before us. Thanks for contributing to that and welcome to the site. – J.Todd Oct 21 '15 at 16:22
  • @JacquesB Yeah, but for small embedded systems, your controller might be the 'button controller' which handles hardware interrupts from a few on-board buttons and the view might be your 'dotted console' view which can write a few numbers out. Obviously, I didn't mean the hardware itself, but the 'drivers' of these – cwap Oct 21 '15 at 17:32
  • 1
    @JonathanTodd: MVC was invented in the Smalltalk community as a pattern for writing GUI's. Not embedded systems. – JacquesB Oct 21 '15 at 21:44
  • @JacquesB note that smalltalk (at least at the time MVC was invented) was a language that targeted small microprocessor systems with only a few hundred kilobytes of RAM and no operating system. The systems it ran on were much more similar to embedded systems than modern PCs, and this was reflected in the architecture: the controller classes did interact with input hardware at a much lower level than modern systems, and this was part of the problem that the controller part of MVC was intended to abstract away. – Jules Oct 23 '15 at 08:34
  • @Jules: The MVC pattern was from the beginning designed for GUI's, it had nothing to do with embedded systems or line-mode consoles. See: https://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls78.html – JacquesB Oct 28 '15 at 16:56
  • @JacquesB I'm starting to get curios as well, but the link doesnt work :( Is the server down or is it behind some sort of firewall? – cwap Oct 29 '15 at 09:19
  • Nevermind - the link works again, so I guess the server was just down – cwap Nov 03 '15 at 07:44