The MVC pattern also fits a client-server application. The only difference is that there are now two pieces that both have their own MVC parts.
Let’s start by defining the two extreme ends of the spectrum (the corner cases):
- Everything runs on the server, and only a static rendering of the model is transmitted to the client and ultimately, the user. This is the model of Web 1.0. Technically there is still a tiny fraction of the V running on the client (the browser) that renders the HTML, as well as of the C that reacts to links. Note that this is commonly referred to as fat server/thin client or ‘terminal server’ approach. Here an update of the GUI always involves a whole round trip to the server. This is depicted in figure 1: Read the rest of this entry »
The MVC model is a very handy and very well accepted model for traditional desktop applications that let the user manipulate some kind of data. Even web-applications (mostly) fit this model nicely.
In a desktop app this normally involves three distinct parts which are like services: they need to work together, but (should) have a well-defined contract/interface. They are all written in the same main language (whichever it is the app is developed in) but the model needs to interface with some kind of permanent storage (persistence) which sometimes involves translating to another language/representation of the model – be it XML, SQL, CSV, LaTEX or whatever. The View on the other hand, will mostly want to create some kind of visual representation of the model which is sometimes described in some other language than the main. That can be HTML/XUL or XML for Qt-based GUIs – you name it. VMs like Java or .NET have their own way of describing – the more appropriate term is ‘creating’ – the interface from within the program using the same main language.
Now think of MVC as applied to web-apps. Do we get by with 3 languages? No, we need more and that makes it so much more complicated.
Server-side frameworks represent the MVC and can thus comprise 3 languages (like in desktop-apps) already. If a part of the V is to be executed on the client, we need JS in the mix. Since that JS code will mostly also need some data (part of the M) we need to translate that part into a form suitable for transfer to the client (commonly known as ‘marshalling’) with throws another language into the mix – JSON, XML or something else – for a total of 5.
What’s more is that this encompasses two distinct systems, each with their own cycles, states and debugging environments. In one word: a nightmare.