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

Revision as of 11:52, 27 July 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.

The 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 architectural pattern leads to increased re-usage opportunities for classes, better modularity, beteer scalability, less dependencies between classes and therefor better maintainability of the entire system.

This can only apply when the MVC triad pattern ist 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.