Difference between revisions of "Architecture/Visions/Model View Controller"

Latest revision as of 13:11, 2 August 2007

Consequent implementation of the Model-View-Controller ( MVC ) paradigm

When software applications contain a mixture of data access code, business logic code, presentation code and control logic they appear to be increasingly difficult to maintain. With the increased size of an application the complexity gets fast out of control because of interdependencies between all of the components. Changes become increasingly difficult, reuse of classes are nearly impossible because of their heavy dependency on too many other classes. Changes or additions to the functionality of the application in terms of new views on data too often require re-implementation or doubling of existing business logic as well as data access code for adaption. This in turn leads to an again increased maintenance effort because changes have to be made at different code locations and needs to be hold in sync.

In large software systems the spiral of tightly coupled code, poor re-usage of classes/functionality and copy-pasted code, often leads to extreme maintenance efforts and significant longer time to market cycles.

A Model-View-Controller ( MVC ) architectural design pattern offers here a way of decoupling data access, business logic, data presentation and user interaction by defining three categories of objects, each specialized on either data access and business logic (Model), the presentation of data (View) or the handling of interaction events (Controller).

The separation of this three categories, known as MVC triad (which origins from Smalltalk80), allows for e.g. different views on the same, shared data model. Consequently implemented in a software system with strictly separated, specialized object categories the MVC like architectural pattern leads to increased re-usage opportunities for classes, better modularity, better scalability, less dependencies between classes and therefor better maintainability of the entire system.

This can only apply when the MVC triad like pattern is transparent to the contributing developers and implemented according to an overarching strategy throughout the entire software system. The challenge in the scope of large software systems like OpenOffice.org is to analyze if and how the MVC paradigm is followed and how contributing developers can be lead to a unified understanding, handling and implementation of this architectural design pattern.

It should be emphasized that MVC here is called a paradigm and should be seen more as an architectural strategy which aims for clear functional separation of classes. What flavor of the MVC paradigm to prefer, is left to imagination and creativity. Is it Presentation-Abstraction-Control (PAC) pattern, Interface-Model_Control (ICM), or a subset or variation of PAC like Hierarchical Model-View-Controller pattern (HMVC).

All of these seem to offer compelling advantages wrt. user experience especially startup time experience due to the possibility of separately multithread the model and the view.