ArticlesTutorialsInterview Questions & AnswersCertificationsFree Books & Sample ChaptersTechnical Discussions  Your Account | Advertise with us | Feedback |
Model-View-Controller (MVC) Architecture

Model-View-Controller (MVC) Architecture

                      Anand, developersBOOK.COM , 12/01/06


A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution.

There are many good reasons to use design patterns. Here are three:


  • They are proven. You tap the experience, knowledge and insights of developers who have used these patterns successfully in their own work.
  • They are reusable. When a problem recurs, you don't have to invent a new solution; you follow the pattern and adapt it as necessary.
  • They are expressive. Design patterns provide a common vocabulary of solutions, which you can use to express larger solutions succinctly.

It is important remember, however, that design patterns do not guarantee success. You can only determine whether a pattern is applicable by carefully reading its description, and only after you've applied it in your own work can you determine whether it has helped any. One of these patters is Model-View-Controller (MVC). Smalltalk defined it in the 70's. Since that time, the MVC design idiom has become commonplace, especially in object-oriented systems.

MVC Architecture

The goal of the MVC design pattern is to separate the application object (model) from the way it is represented to the user (view) from the way in which the user controls it (controller).

The Model object knows about all the data that need to be displayed. It also knows about all the operations that can be applied to transform that object. However, it knows nothing whatever about the GUI, the manner in which the data are to be displayed, nor the GUI actions that are used to manipulate the data. The data are accessed and manipulated through methods that are independent of the GUI. The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model.


The View object refers to the model. It uses the query methods of the model to obtain data from the model and then displays the information. A view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes.


The Controller object knows about the physical means by which users manipulate data within the model. A controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.


In GUIs, views and controllers often work very closely together. For example, a controller is responsible for updating a particular parameter in the model that is then displayed by a view. In some cases a single object may function as both a controller and a view. Each controller-view pair is associated with only one model, however a particular model can have many view-controller pairs.


The MVC architecture has the following benefits:


  • Multiple views using the same model: The separation of model and view allows multiple views to use the same enterprise model. Consequently, an enterprise application's model components are easier to implement, test, and maintain, since all access to the model goes through these components.
  • Easier support for new types of clients: To support a new type of client, you simply write a view and controller for it and wire them into the existing enterprise model.
  • Clarity of design: By glancing at the model's public method list, it should be easy to understand how to control the model's behavior. When designing the application, this trait makes the entire program easier to implement and maintain.
  • Efficient modularity: of the design allows any of the components to be swapped in and out as the user or programmer desires - even the model! Changes to one aspect of the program aren't coupled to other aspects, eliminating many nasty debugging situations. Also, development of the various components can progress in parallel, once the interface between the components is clearly defined.
  • Ease of growth: Controllers and views can grow as the model grows; and older versions of the views and controllers can still be used as long as a common interface is maintained.
  • Distributable: With a couple of proxies one can easily distribute any MVC application by only altering the startup method of the application.


Next Struts FAQs & Struts Tutorials


Add this to :
Spurl Slashdot
Y! MyWeb


About Us | Our Mission | Terms of use | Author Terms |    Search        | Contact Us | Advertise With Us | Link to Us | Sitemap
Copyright © 2016 developersBOOK.COM. All rights reserved.
); ?>