Tag: mvc

About

Model–view–controller (MVC) is an architectural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC, the model represents the information (the data) of the application; the view corresponds to elements of the user interface such as text, checkbox items, and so forth; and the controller manages the communication of data and the business rules used to manipulate the data to and from the model.

History

MVC was first described in 1979 by Trygve Reenskaug, then working on Smalltalk at Xerox PARC. The original implementation is described in depth in the influential paper Applications Programming in Smalltalk-80: How to use Model–View–Controller.

There have been several derivatives of MVC; one of the most known (due to its use by Microsoft) is the Model View Presenter pattern which appeared in the early 1990s and was designed to be an evolution of MVC. However Model–View–Controller still remains very widely used.

In November 2002 the W3C voted to make MVC structures part of their XForms architecture for all future web applications. These specifications will now be integrated directly into the XHTML 2.0 specifications. There are now over 20 vendors that support XForms frameworks with MVC integrated into the application stack.

Pattern description

Model–view–controller is both an architectural pattern and a design pattern, depending on where it is used.

As an architectural pattern

It is common to split an application into separate layers that run on different computers: the presentation/user interface (UI), business logic, and data access. In MVC the presentation layer is further separated into view and controller, resulting in three layers.

MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML. Finally, the model is represented by the actual content, which is often stored in a database or in XML nodes, and the business rules that transform that content based on user actions.

Though MVC comes in different flavors, control flow is generally as follows:

  1. The user interacts with the user interface in some way (for example, presses a mouse button).
  2. The controller handles the input event from the user interface, often via a registered handler or callback.
  3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (for example, the controller updates the user's shopping cart).
  4. A view uses the model indirectly to generate an appropriate user interface (for example, the view lists the shopping cart's contents). The view gets its own data from the model. The model and controller have no direct knowledge of the view.
  5. The user interface waits for further user interactions, which restarts the cycle.

Some implementations such as the W3C XForms also use the concept of a dependency graph to automate the updating of views when data in the model changes.

By decoupling models and views, MVC helps to reduce the complexity in architectural design and to increase flexibility and reuse of code.[citation needed]

As a design pattern

MVC encompasses more of the architecture of an application than is typical for a design pattern.

Model
    Is the domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).
    Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model.

View
    Renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

Controller
    Processes and responds to events (typically user actions) and may indirectly invoke changes on the model.

From en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

 

So I've been learning CakePHP the last few days. Bit by bit I've been trying to port a lecagy admininistration app to Cake. 'Secretly' linking menuitems to finished Cake parts as we go. And I must say: I'm pretty excited. I did run into a disturbing conclusion though. I estimated the legacy app will have over 300 Models & Controllers once finished. That could easily add up to (300 x 4 =) 1200 views. And here I am, creating a maintenance hell while trying to solve one!