Model-View-Controller

This pattern is primarily used in user interfaces. It allows an abstraction of the components of a GUI to support easy development, maintenance, and extensibility. The MVC pattern attempts to address the “right way” to do GUI’s.

First we need some definitions:

Model – The program itself (data and application)

View – Input and output of the program that interacts with the user (graphical display)

Controller – Links views and models.

Function:

• The controller connects the model and view. Some MVC implementations show the controller accomplishing interconnection through use of the adapter design pattern. In this case, adapters serve to provide translation between the view and model.
  
• -The model and view should be kept expressly separate. A view should work with any model and a model should work with any view.
  
  • Models should work with arbitrary views.
    
  • Views should work with arbitrary models.
    
• Controller’s instantiate the model, view, and adapter(s) and initialize communications between them.
  
• View exists to meet the interaction and feedback needs of the user.
  
• View is broadly defined as any object that needs information about the model.
  
• Model maintains the state and data the application represents.
  
• To see the real function of the pattern, expand the model and view in the above pattern to be hundreds to thousands of sub-objects.

Why:

• (PRIMARY) MVC pattern avoids problems that occur when the model and the view are tied together. If components are bundled together they become much more difficult to change.|
  
• The need for this pattern is less evident in simple user interfaces. The number of components is small, and the consequent overhead to change is low. In a large UI, the problem of change compounds.
  
• By decoupling the model and view MVC allows separation of work. One group can deal with the model while a separate group could tackle the look and feel of the view.