Sunday, September 23, 2012

The missing 'S' in MVC

MVC (or as I prefer : MCV ) proved to be a very useful design pattern for compiled applications. Using this pattern, a developer could create a tool to visualize how the application is working internally. Each layer would have a dedicated part presenting the current state of each layer.

Model Controller Views

What about dynamic schemas ?

A problem with this pattern starts to emerge once application logic can be changed while the application is running.

Suddenly, three layers aren't enough. A schema layer needs to be inserted somewhere in the pattern if we want to visualize parts such as the model definition or the rules defined in a controller. The role of the schema layer is to contain the definition of object structures and the logic that govern them. In other words; the class and the method definitions.

Adding this layer at the start of the pattern would lead to SMCV.

Schema Model Controllers Views


While functional, this layer representation has a few dependency problems : It implies that the layers above the schema layer can depend on all the content in the schema. For instance, the model can depend on controller or view definitions.

The solution to all software problems : Add more layers !

To clean up dependency cycles, a better solution is to split the schema in a dedicated layer for the model, the controller and the view.

The only problem left is the terrible acronym for the pattern : SMSCSV.

Schema Model Schema Controllers Schema Views

This is the standard layers that ended up forming my typical applications on the Deduced Framework.

Typical layers of a Deduced Application

This view allows multiple users or developers to collaborate on a running application to monitor and apply change on any layer, demonstrating another interesting side effect that dynamic schemas introduce on traditional software design patterns.

2 comments:

  1. Replies
    1. One obvious alternative is to skip some of the MVC layers altogether. For instance, implement all the controller logic directly within the model. Skipping layers is usually convenient for small applications and quick prototypes.

      For example, when someone edits spreadsheet, the Model and the View are practically the same thing so they could be viewed as one layer.

      Other patterns such as Model View ViewModel (MVVM) and Model View Presenter (MVP) aim at splitting the View layer in smaller layers that are used to facilitate remote user interfaces and to potentially improve code reuse.

      I used the MVVM pattern to create a web view on top of my deduced applications. The "Application View" layer on top contains an object model that represents the state of every UI components while the "Application View Schema Model" contains the logic to be executed when events occur on the UI.

      Cheers.

      Delete