Model View Controller Architecture

Introduction

What is MVC? Model-View-Controller (MVC) is a classic Design Pattern often used by applications that need the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean separation of objects into one of three categories - models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view.

MVC is the Model View Controller Design Pattern. If the application has good MVC separation, we can add new features to the existing application easily. But it will take more effort to use the new features if you don't have a good separation.

Why do we go for the MVC Design Pattern if good old MFC already has provided the doc/view architecture for us??

Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design. The MVC pattern allows any number of controllers to modify the same model.

The Model-View-Controller (MVC) is a commonly used and powerful architecture for GUIs as well.

The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, output roles into the GUI realm:

• Input --> Processing --> Output
• Controller --> Model --> View

Using the Code

The user input, the modeling of the external world, and the visual feedback to the user are separated and handled by the model, viewport, and controller objects. The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or viewport to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The viewport manages a rectangular area of the display, and is responsible for presenting data to the user through a combination of graphics and text.

• Model: To manage information and notify observers when that information changes. It contains only data and functionality that are related by a common purpose.
• Viewport: The [view or viewport] is responsible for mapping graphics onto a device. A viewport typically has a one to one correspondence with a display surface and knows how to render to it. A viewport attaches to a model and renders its contents to the display surface. In addition, when the model changes, the viewport automatically redraws the affected part of the image to reflect those changes. There can be multiple view ports onto the same model and each of these view ports can render the contents of the model to a different display surface.

A viewport may be a composite viewport containing several sub-views, which may themselves contain several sub-views.

• Controller: Controller is the means by which the user interacts with the application. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button or chooses a menu item, the controller is responsible for determining how the application should respond.

1. The model's viewport pointer is only a base class pointer; the model should know nothing about the kind of viewports which observe it.
2. The viewport also has a strongly-typed pointer to the model, allowing it to call any of the model's functions. In addition, the viewport also has a pointer to the controller, but it should not call functions in the controller aside from those defined in the base class. The reason is you may want to swap out one controller for another, so you'll need to keep the dependencies minimal.
3. The controller has pointers to both the model and the viewport, and knows the type of both. Since the controller defines the behavior of the triad, it must know the type of both the model and the viewport in order to translate user input into application response.

Sample

Here is a sample: a modal dialog with a text box and a label.

It should be almost effortless to use new features if your application has a good MVC separation.

Class MyCtlr
{
    public:
    virtual CDialog* CreateInstance();
}

Class MyDialogCtlr
{
 
public:
     MyDialog* m_pDialog;
     MyDialogModel* modelData;
     CDialog* CreateInstance(); 
};

MyDialog* MyDialogCtlr::CreateInstance();
{
     m_pDialog = new MyDialog;
     return m_pDialog;
}

Class MyDialog: public CDialog
{
public :
    Bool InitDialog();
     MyDialogModel* m_pModel;
     MyCtlr* m_pCtrlr;
     CTextBox *m_pTextBox;
};

MyDialog::GetModel()
{
    return m_pModel;
}

MyDialog::MyDialog():CDialog()
{
    m_pModel = new MyDialogModel;
}

MyDialog::InitInsatnce()
{
    m_pTextBox = new CTextBox;
}

OnOk()
{
    m_pModel->m_csText = m_pTextBox.GetText();  
}

class MyDialogModel 
{
public: 
    CString   m_csText;  
};

MyDialogModel::MyDialogModel()
{
    m_csText = _T("Arti");
}

singleton Model class
OnShowDialog()
{
   MyDialogCtlr ctlr;
   MyDialog *pDialog = static_cast<MyDialog*>(ctlr.CreateInstance());
   ctlr.SetModel(pDialog->GetModel());
   if( wxOK == pDialog->DoModal() )
   {
   }
   else
   {
   }
}

Points of Interest

The MFC Framework's Doc/View architecture is basically the MVC itself. The beauty of this lies in MFC's API UpdateAllViews() which invokes the OnUpdate() of all the views and gets updated accordingly.