MVC design pattern in our project, the Order system

In our project, because of the distributed characteristic, we choose the representative MVC pattern to do our implementation. 

A model notifies its associated view/views and controllers when there has been a change in its state. This notification allows views to update their presentation, and the controllers to change the available set of commands. In some cases an MVC implementation might instead be “passive” so that other components must poll the model for updates rather than being notified.

A view is told by the controller all the information and it needs for generating an output representation to the user. It can also provide generic mechanisms to inform the controller of user input.

A controller can send commands to the model to update the model’s state (e.g, editing a document). It can also send commands to its associated view to change the view’s presentation of the model (e.g, by scrolling through a document).

The structure of our project is as follow:

It is evident that the structure can be represented by this:

For the details, we can show our project structure by this:

Typically, the Model set in the server, and the server (model) handle all the event logic of the whole system. In terms of the whole system, there are many clients. Each client has its own controller and view but not have the model itself.


Obviously, the distributed kernel is demonstrated here. All the clients share the common Model which is set in the server, that means all the users’ requirements are delivered by their own controllers, then the controllers send the events logic to the common model, afterwards, the model handle the event logic of the clients and change its corresponding state. Because all the views are the dependences of the model, views can change their corresponding presentations and show themselves to the clients almost synchronically. And here the synchronization perfectly meet the requirement of our project, the Order system.