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
  • 23
  • 27

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,749
  • 7
  • 106
  • 173
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
  • 61,955
  • 21
  • 135
  • 189
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