Introduction
MVC
Model View Control (MVC) is a 3 level architecture that decouples the interface from navigation and application behavior, mostly because keeping the applications together creates a huge mess when it is time to redesign you program. MVC patterns will simplify implementation and greatly enhance re-usability. It should always be used in O.O.P. (object oriented programming)
Model
The term Model stands for Data Module Objects, it holds all the application state information (ie data) and all operations that can modify the data.
A model is a computational approximation or abstraction of real world process, entity, or system. An example is the shopping cart when you order an item on-line using e-commerce. It would hold the information of the order number, what is being ordered, the quantity being ordered, and all the code that could interact with this data usually in SQL code. It is also called business logic and provides the connections to the data source as well as to the controller.
View
The view contains the interface functions, it is the GUI code. It will produce all the visual components of your program. It provides the access to the data and processing logic to the user.
It needs to allow the user enough functionality to provide the user with the tools the program is being developed for.
The view is tied into the Data model, if you delete an item from a shopping cart it will be removed immediate or upon a page refresh usually from an Event Object handler that contains the change and then updates the cart to show a page in HTML with the previously deleted item gone.
For an inexpensive home server try a Linux server with Apache Web-server, a MySQL database and PHP coding. All the software can be installed for free.
Controller
As its name implies, the controller component controls the overall flow. The controller code interacts with the view and model components to deliver a modular yet integrated solution.
It is the Controller that accepts input from the user in a particular modality, interprets that input (the interpretation may depend on the View), and invokes the appropriate operation on the Model.
For example, when the Controller detects a mouse click event on the “remove” button of an item it invokes the remove operation on that item. Any state changes that this operation causes on the
Model are sent by the Model to the registered Views via events. The controller component is normally written in Java and implemented as a Servlet.
MVC usage rules
In order to support reusability, the interactions which do occur should be well defined and the dependencies between the elements (M-V-C) should be minimized. One of the goals of the MVC pattern is to enable the combination of a single Model with multiple Views and Controllers. The MVC pattern ensures that the Views are kept synchronized. When the Controller recognizes a valid command from the user’s input, it invokes the corresponding method on the Model. The
Model verifies that the operation is compatible with its current state, executes it and changes the state of the Views correspondingly. The views, as they have registered themselves as observers, get now informed about the Model’s state change and update their rendering correspondingly.
The dependencies must be kept minimal
To support multiple views and controllers the dependencies must be kept minimal.
Note: A is said to be dependent on B when the code of A embeds knowledge about B.
This leads to the following rules:
- The Model does not have any dependency on Views or Controllers.
- A View depends on its associated Model. It has to know the structure of the Model’s state to be able to render it.
- A View does not have a dependency on Controllers. Therefore several different Controllers can be associated with the same View.
- A Controller depends on its associated Model and View. The Model defines the operations the Controller can invoke and the View defines the context in which the Controller interprets the user input. This makes the Controller tightly coupled to the View.
The interactions must be kept minimal
Another precondition to support multiple Views and Controllers is to keep interactions minimal.
In particular a Controller must never directly affect the rendering of its associated View. Instead user input must make a complete round trip through the Model before its effects become visible in the View. This rule guarantees that a state change updates all Views and that the Views remain synchronized. Often implementations with a single Controller violate this rule because of sloppy
thinking: “I already know that this state change will occur, and therefore do not need wait for the Model to tell me about it”. This is wrong for two reasons:
1. The Model can veto the operation for some reason. The operation will not occur.
2. Other Controllers may concurrently invoke operations on the Model. Some other operation can slip in between, which fundamentally changes the rendering and makes any assumptions about it invalid.
In addition it is impossible to extend such shortcut implementations later with additional Controllers.
The MVC pattern in Web applications
Although the MVC pattern was originally devised for the organization of fat client GUI libraries, it has in the past several years received widespread acceptance as a suitable architectural pattern for implementing Web based solutions, too. Its structure has been applied, (with limitations), in recent Web applications. This is not surprising, since in both cases the separation of concerns is the driving force behind architectural choices.
Extending the MVC pattern to distributed applications
Although the MVC pattern was originally devised for GUIs running on a single machine, it can be extended relatively straightforward to distributed systems, where some interfaces between Model, View and Controller may cross the network. The placement of the Model, the View and the Controller then becomes a crucial issue.
The client-centric approach puts all three functions: Model, View and Controller on each client device. The Model, which exists conceptually only in one instance, is “replicated” among the devices. A replication protocol keeps the copies of the Model synchronized.
The server-centric approach puts both Controller and Model on a server. The client devices contain only the Views.
Why you should MVC
- Separation of data from presentation
Drawbacks on MVC
- Is not easy and requires planning
- Thorough testing and more files needed
- May overkill small applications
