Using MVC (Model View Controller) in a Client-Server architecture

Question

I'm trying to choose an design pattern for an application that I'm developing. The application is primarily based on a Client-Server architecture where the Client basically reads and writes data to the Server; its not a Web-application however, The client will have to install the software executable and then interact with a GUI in order to communicate with the Server (which exits on a different machine) through an internet protocol.

Since the application is based on heavy interaction with a GUI, I was thinking about using the MVC design pattern, the thing is I'm having trouble deciding which part should exist on the Server and which on the Client side. In other words, is it ok to have the View (i.e the Boundary GUI classes and objects) and the Controller on the Client side, while leaving the Model (i.e the Entity objects) on the Server side; is this a viable or valid way of applying the MVC pattern ? Am I going in the right direction here ? Is this even possible ? I mean can those Boundary and Control classes operate and execute without having or accessing the Model classes on the same machine or process ?

Should I have the whole thing (The Model, View and Controller classes) on the Client side and then just communicate with the Server database via the protocol ?

Any suggestions or comments would be welcome.

Answer 1

For a flexible architecture you may have coupled controllers, i.e., cliXController and srvXController, one for the client side and one for the server side. With this splitting, you will have a flexibility for various decision points, such as putting View component to client or server side, or maybe to the both sides. You may want server side rendering for some of the views and client side rendering for some of the views. On the other hand, I would suggest to put all the Model component to server side for various reasons mentioned in other answers.

Answer 2

You can't really apply traditional MVC to server-client architecture. Reasons include:

• The server and client has different runtimes and APIs.
• You must have some business logic on the server for security reasons, but unless every user action does the roundtrip to the server and back you must have some business logic on the client side as well (think about form validation). In effect, this means you have the model on both.
• In traditional MVC the controllers maintain a reference to the model. A controller on the client side can't really keep a reference to the model on the server because the network facade.
• What's more, in traditional MVC the model layer has all the model records. In many web applications the client only gets partial model (think page 1 out of 3).
• The two last points also mean that the (partial) model in your client is not really your model - if there are two views for the same model (think a paginated list of clients, and a typeahead dropdown with remote search on a different view) there are also two controllers - each with its own model. Thus the model is in effect a phantom view model and not real model.

There're many more reasons, but I think the above demonstrates the point.

There are various ways to combat this, getting something very close to MVC can involve a model proxy on the client side. To the more abstract/flexible command based agent-like architecture.

Answer 3

After a lot of R&D I found best performance with the majority of the controller and the view on the client, and also a small part of controller and model on the server. You could then say the controller was split across client and server - the benefit being that if the controller needs assets that are already cached in the client, it actually avoids network traffic which is important in making things run fast. Here is an example: http://www.youtube.com/watch?v=g73GcQqrDeA

Basically I found that performance was bad if using such things as server-side template engines or anything that can for a cache miss from the browser, so all html must be 100% static. Using jQuery only, out of the box it provides really useful event binding facilities that you can delegate to a Controller Class that is also cacheable at the browser. In the end, the only data going back and forth is JSON - just take care in making your server secure, encode/encrypt all important identifiers, make sure they aren't the same for even the same user between sessions etc...

Answer 4

There are a lot of ways of implementing MVC in a client-server setting. In general, the more stuff you put in the client the "richer" or "fatter" your application becomes. So, if you decide on using MVC, the real question for you then becomes: how rich do I want my application to be?

Also, you can have multiple instances of MVC working together in one application, distributed over client and server.

Some of the things I would look at:

• network: How much data needs to be shuttled between client and server? How many requests will an application typically send? (too much may saturate the network or cause other trouble)

• responsiveness: higher responsiveness can require you to put more in the client

• security: everything that goes over the wire may be less secure

• performance: if you need high performance, you may need components on the server

• expected loads: you may decide to put more components client-side to offload the server, instead of clustering your backend for example

• etc.

Answer 5

Your thoughts about using MVC is quite right. This will help you de-couple things and will give you more control on classes.

I would suggest keeping the view on the client side. I would keep the controller and model classes on the server. Controller is the component that's tricky. One may be easily tempted to keep it on the client, reasons to put it on the server would be: interactions with DAOs, interactions with Model classes, error handling and control flow (of screens/actions).

A controller on the client side may prove to be easy to develop but ultimately you need to pass changes (like button presses, clicks etc etc) to the server. Further, a controller on the client side would then slowly start pushing you towards more and more classes on the client side.