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

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.