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:
- Everything runs on the client except a very thin layer for storage abstraction (part of the M) on the server. Note that the crucial part here is that almost the whole code runs on the client, it does not matter where it comes from. It could have been downloaded and installed by the user in a separate (AD) step before (like an FTP client, widget etc.) or it is downloaded at the moment the user visits the website. The small (thin) part running on the server essentially provides a service to the (fat) client, thus this is the textbook example of SOA. Only data is transferred from the server to the client according to an agreed-upon format. It could also be a remote DBMS or a network filesystem like NFS. In this model the application-cycle runs completely on the client. Ironically, the case that a disk-less client connects to a server, mounts its whole FS over the network and then runs programs on the client, is commonly defined as a thin-client (because it looks at the hardware as a whole) – although according to the description given here it should be called fat-client (referring only to the software). The following figure shows this graphically:
All of today’s client-server applications, and web-applications for that matter, lie between these two ends of the continuum. It depends on the environment, the requirements of the software and ultimately, the developer to the decide where to draw the line between client and server. All three ingredients of the MVC are broken up and divided between the server and the client. Each part communicates in a specific language. In a web-application today the picture looks like this:
Obviously, this line cannot be drawn just anywhere. There are a lot of things to be taken into consideration. Before I break it up by parts, here are some general remarks.
The model of the web today brings with it the assumption that the customer can connect from anywhere with any device and always sees the same interface and data. This means, that all the data needs to be replicated or stored at the server – always, in case the customer connects from a different device and all state from a previous session is lost. Also note that everything should be broken up into small parts and separated by dynamic and static content for easier caching, which is a big drawback for RIAs because they ultimately package everything in one big download.
Now, I name specific considerations that apply to some part of the MVC.
- M: Parts of the data that are crucial for the business-flow and also validation, as well as internal info should always be kept at the server. Some parts of the model that pertain to the customer might also be replicated client-side for faster bootstrap. But keep in mind that this data might get lost and also end up in the wrong hands. Thus, always provide an option to delete all stored data. Never trust data stored on or coming from the client side unless it is stored/transmitted securely and/or validated strictly. A shopping basket is a good example of data that can be kept client-side until the order is placed in which case it gets transferred to the server. Customer info – like address – can be replicated at the client but also needs to be at the server for the companies own use; this also necessitates keeping it synchronized. Data marshaling can be considered part of the M and is evenly divided between client and server. In summary, the bigger part of the M will be kept at the server.
- V: Most of the V can be generated client-side. For faster startup, the server can generate the initial view and send it to the client. Only because the specifics of the application or the device might be lacking enough processing power (ex. mobile) which mandates server-side rendering should that still be possible.
- C: Since this interacts mostly with the user and is dependent on the view, the C will for the most part be wherever the V is.
What the affluent reader should get from this is that all these point towards SOA architecture. As depicted in the web-apps figure above, this model places most of the Model on the server, whereas most of the view and control live on the client: The server mostly provides a service.
Today, the developer still has to decide where to draw that line. I think that is unneccesary and in the future, compilers might very well be able to decide that for themselves given some definitions of the requirements (like the above). After 30 years of research, compilers were able to match hand-crafted assembler code written by humans. We are possibly looking at a long while until that happens, but I do think that in the future there will be a single, integrated development environment for web-applications. Where everything can be programmed as a single app and the compiler decides where to break it up and compiles it into two distinct parts for the server and client, as well as the marshaling code for transferring and syncing the model between the two pieces.