Understanding the MVC Paradigm

MVC is a design paradigm or design pattern that emerged out of user interface development. Some people attribute it to Small Talk UI. At any rate, the real focus is to try to figure out how to structure a user interface application around good object oriented programming (OOPs) concepts like encapsulation, cohesion, loose couplings, and abstractions. All of these object oriented programming concepts can create re-usability.

If we were to dissect a user interface in the MVC world, in general we’d find three components:

1. The view is responsible for rendering the UI and is directly tied to a model for the state data of the UI. More specifically, as the view renders itself, it calls out to the model and gets back information from the model, so that it could draw a check-box either as a selected check-box or an unselected check-box, depending on the model structure.

2. The model contains the state data for the UI and supplies information to the view as requested.

3. Depending on the MVC paradigm, the controller functions as a traffic cop to allow the interactions that are triggered through the UI to propagate through the model. So, if somebody selects a check-box, that selection is going to go through a controller, and that controller is going to (hopefully) update the model. Then, the model notifies the view and the view redraws itself.

Of course, there are many ways an MVC architecture can be structured. In the interests of simplicity, we will not cover that information here. However, there are two main kinds of competing architectures or ideas on how an MVC framework should be implemented, and they are very important in making your decision.

The two types of MVC frameworks that you will encounter are:
1. Action-based (aka Push-based MVC) frameworks are the most common partially because they’ve been around longer (e.g. Struts). The idea is that when a request comes from a web browser and goes to a web server, there is a request handler that functions as a controller. That request handler takes the request data, puts it into some type of model, and that model then pushes that to the view — typically a JSP. Then, the JSP takes the model data and renders itself. Typically, it’s easy to understand and a very straight-forward process.
2. Component-based (aka Pull-based MVC) frameworks focus on rich UI development. They’ve moved away from the concept of request-processing a little bit, into view generation or view rendering. Included is a nice UI component set that creates re-usability within the application. Three of most common ones are JSF, Wicket, and Tapestry. With Component-based MVC frameworks, it is the view’s responsibility to pull in data from potentially multiple controllers and render itself. Instead of having the controller give all the appropriate data, the view can pull in all the data from the appropriate controllers. There is still a model, and the model is still generally represented as a Java object. The model still could be a composition of objects; the difference is how the view accesses the information.