Model-View-Controller (MVC) architectural style

The **Model-View-Controller (MVC) architectural style** is a model for setting up the relationship between a user interface and the domain-specific portion of a program. MVC divides a program's components into three categories:

* *Models*: The portions of the program that realise problem-domain function. The models holds data and operations for achieving the computation goals of the program independent of its user interface.
* *Views*: Components that display data to users. The data displayed in views comes entirely from one or more models. Labels and graphics are examples of views.
* *Controllers*: Components that receive and carry out commands from users. Controllers may alter views or models. Buttons and scrollbars are examples of controllers.

The views and controllers together comprise a program's user interface; models are entirely separate from the user interface.

I. **MVC Static Structure**: The static structure of the MVC styles uses the Layered style: A program is partitioned into a user interface module, consisting of views and controllers, and an application domain module, which contains all the models. The Layered-style dynamic constraint that a higher layer is allowed to use only the layer directly beneath it is also satisfied in the MVC style. Views and Controllers are allowed to use models, but models do not use controllers or views. The structure of the MVC style is shown in the UML class diagram below:

**MVC-Style Static Structure**

In this figure, the packages represent program layers. The **User Interface** layer includes one or more controllers and views, represented here by **Controller** and **View** classes, and the **Application Domain** layer contains one or more models, represented here by the **Model** class. **Controllers** can use **Views**, and both **Controllers** and **Views** can use **Models**.

II. **MVC Dynamic Structure**: The dynamic structure of the MVC style is fairly simple. The user only manipulates controllers. A controller may alter a view or a model. If a view is altered by a controller, it redisplays itself, perhaps interrogating one or more models to obtain the data it needs for display.

If a controller alters a model, the model responds by doing whatever computations are required. Once it is done, the model issues a notification that it has changed. This may be done by announcing an event or by directly notifying controllers and views. In either case, the model issues an event or notification only, and does not depend on any response. As a result, the model does not use any views or controllers and it is not strongly coupled to them. Views and controllers that receive the model’s notification can reconfigure or redisplay themselves, interrogating models as necessary to obtain data. The sequence diagram below illustrates this interaction in a schematic example with a single view, controller, and model. The model notifies the view and controller of changes by calling a notification operation rather than announcing events.

**MVC-Style Dynamic Structure**

The diagram shows a paradigm interaction in which a **User** manipulates a **Controller** object. The **Controller**  changes a **Model** instance. The **Model** makes the indicated change and then notifies the **Controller** and a **View** object. Each queries the **Model** for data to update itself. A similar course of events ensues if the model changes in response to some application-domain event,such as the passing of time.

III**. Advantages and Disadvantages**

The MVC style is very widely used because it has the following advantages:

* **Advantages**:
	+ Views and controllers can be added, removed, and changed without disturbing the model. The user interface components are almost completely decoupled from the application-domain components,making it easy to change the user interface. Because user interfaces are among the most volatile portions of programs, this greatly increases program changeability and portability.
	+ Views can be added or changed, even during execution. Separating views from controllers makes it is easy to add, remove, or change views without affecting the way the user interacts with the program. This provides view flexibility and configurability without confusing users.
	+ The components of the user interface can be changed, even at runtime. The look and feel of the program can be changed by replacing views and controllers.

However, there are also some disadvantages to using the MVC style:

* **Disadvantages**:
	+ Views and controllers are often hard to separate. For example, a text box is typically both a view and a controller component. This makes it harder to change views and controllers independently, but does not affect the separation of program layers, so it is a relatively minor problem. A single user interface component plays both view and controller roles.
	+ Frequent updates may slow data display and degrade user interface performance. When a model changes, it simply notifies the views and controllers that it has changed. It is up to them to figure out how the model has changed and update themselves. This may require many query operations from the views and controllers to the model, slowing user interface update operations.
	+ The MVC style makes user interface components highly dependent onmodel components. Although the model does not know anything about views and controllers, the views and controllers depend intimately onthe models. Hence, if the models change, the views and controllersusually must be changed too.

Despite some drawbacks, the MVC style is an excellent and widely used style for designing the connection between the user interface and the rest of a program.

Source: Book - Introduction to Software Engineering Design Processes Principles and Patterns with UML 2