Saturday, 1 September 2012

MVC Architecture

Most of the applications need to support multiple types of users with multiple types of interfaces. For example, an online store may require an HTML front for Web customers and a WML front for wireless customers.

Our applications contain a mixture of data access code, business logic code, and presentation code. Such applications are difficult to maintain and reuse, because of interdependencies between all of the components (one class depends on many other classes). Adding new data views often requires re-implementing or cutting and pasting business logic code, which then requires maintenance in multiple places.

The Model-View-Controller (MVC) architecture solves these problems by separating data access, business logic and data presentation. Such separation allows multiple views to share the same data model, which makes supporting multiple users with different interfaces.

ModelThis represents the state of the component (i.e. its data and the methods required to manipulate it) and is independent of how the component is viewed or rendered.

View - The view displays the contents of a model and specifies how that data should be presented. We can have multiple views for the same model within single applications or model may have different views in different applications or operating systems.

ControllerThe controller translates interactions with the view into actions to be performed by the model. They appear as GET and POST HTTP requests. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

Earlier there was no MVC. Then we had MVC Model 1 and MVC Model 2 architectures. After that web application frameworks such as Struts (MVC 2) came. Finally, now we have a standard web based application framework i.e. JavaServer Faces (JSF).

MVC Model 1
A Model 1 architecture consists of a Web browser directly accessing Web-tier JSP pages. The JSP pages access JavaBeans that represent the application model.

In Model 1 architecture, the current page being displayed determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). Here, choosing next page to display occurs in scriptlet code, but this usage is considered poor form.

The JSP page alone is responsible for processing the incoming request and replying back to the client. There is still separation of presentation from content, because all data access is performed using JavaBeans. But view and controller part are still handled by single JSP file.

Although this architecture is perfectly suitable for simple applications, it may not be good for complex implementations. Random usage of this architecture usually leads to a significant amount of scriptlets embedded within the JSP page.

MVC Model 2 Architecture
This architecture introduces a controller. We can implement controller using JSP or servlet. It gives the following advantages:

1) It centralizes the logic for dispatching requests to the next view depending upon request URL, input parameters and application state.
2) It gives the single point of control to perform security checks and to record logging information.
3) It also encapsulates the incoming data into a form that is usable by the back-end MVC model.

The following figure shows the architecture and functioning of the application that is built using MVC Model 2 architecture:

The client (browser) sends all the requests to the controller. Servlet/JSP acts as the Controller and is in charge of the request processing and creation of any beans or objects (Models) used by the JSP.

JSP is working as View and there is not much processing logic within the JSP page itself, it is simply responsible for retrieving objects/beans, created by the Servlet, extracting dynamic content from them and put them into the static templates.

No comments:

Post a Comment