Friday, April 29, 2011

Chapter 56: Model View Controller Pattern

In this chapter, we are going to take a look at one of the most commonly used design patterns in J2EE Application development – the Model View Controller – MVC Pattern.

What is the Model View Controller Design Pattern?

The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller). This pattern is the hardest on the exam. The idea is closely related to the recent move from two-tier to three-tier architectures. The 3 tiers in a MVC Architecture of a J2EE Application are:

1. Model – Usually JavaBeans
2. View – Usually JSPs
3. Controller – Usually Servlets


This pattern is a clear functional separation of roles. It is a formalization of the data-business-presentation movement that dominated three-tier architectures over the last decade.

Is Not

This pattern is very abstract. It is not simply a front end to a datasource connection.


This would be like an automobile. The speed of a car is affected by the accelerator pedal (Controller), the speed is shown by the speedometer (View), and the speed is determined by the engine power (Model).


Different views of the same data are a common need. Conversely, the same client needs access to different models.


This pattern carefully manages communication between the client and model data and functionality. It must allow changing the client or changing the model with minimal impact on the system.


The main goal is separation of concerns. This pattern attempts to minimize the impact of changing any of the three pieces.

Primary Activity

This pattern decouples views from data and business logic; MVC interjects a controller between them, which interprets user actions into operations on the business logic and the selection of the next view to send to the user.


An application is expected to support varying client and business logic tiers.


• Various clients and data models are being developed. These two tiers need to talk to each other.
• Non-interface-specific code is duplicated in many applications.
• The same enterprise data will be accessed by different views: for example, HTML, WML, JFC/Swing, and XML.
• The same enterprise data will be accessed (requested, modified, and deleted) from various actions (HTML links, JFC/Swing events, SOAP XML calls).


Although the primary purpose of MVC is for building UIs, it can be used to establish an analogous notification protocol between non-visual objects. The Observer/Observable objects in java.util were designed with this pattern in mind.


• Clients access a controller that accesses the model instead of the data directly.
• Another layer has to be built which adds work.
• It is easier to break a project into pieces because both the view and model developers are targeting the controller API.


Almost all J2EE applications use the MVC Pattern. Even JFC Swings technology of Java uses the MVC Pattern. Also, Struts and Velocity use this pattern as their underlying framework.

Previous Chapter: Chapter 55 - Business Delegate Pattern

Next chapter: Chapter 57 - Front Controller Pattern


  1. Good post. I have written a simple web application example using MVC pattern. You can find it here

    ps: This example will be useful for readers after reading your design pattern explanation.

  2. Hi

    I read this post 2 times. It is very useful.

    Pls try to keep posting.

    Let me show other source that may be good for community.

    Source: financial controller interview questions

    Best regards


© 2013 by All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.