Blog‎ > ‎

An Extension to MVC architectures

posted Feb 17, 2013, 6:34 PM by Evan Morrison   [ updated Feb 20, 2013, 3:35 PM ]
A common system architecture currently is the model view control (MVC) paradigm. This way of development encourages developers to distribute development into the view-points of models, which are connected to the file system or database systems, views, which deal with the UI and UIX, and controllers, handling application logic and flow. It is a pattern that has many good points and re-enforces a distinction between each system aspect; however, anyone who has developed any system based on this paradigm will tell you that most applications developed using an MVC architecture is complicated. For me, the pain point is the weighting of the controller design in these systems. Logic and application flow make up a large part of most applications so typically when analysing a completed MVC application it's not uncommon to find that 5% of code is the model code, 25% of code is view code and the rest is in the controllers. This is a serious problem because although there is separation to view and model, the controller code is often reused and unmaintainable.

In my most recent work on the Oolieyah-CPN, and a little geo-aware Hide and Seek app, I've been working on an extension to the MVC architecture that I am referring to as MVCSPR. It has the classic elements of model, view and controller with the addition of processes, rules, and system functions. In the next few paragraphs, I’ll discuss each component of the system and then explain how they all fit together.

Starting with the process layer of the system, a process contains details of the functional application flow. Each activity in a process is an action that is performed on the system state. Activities in a process may be performed as system functions, or human mediated functions imputed through the UI.

Rules are the personalisation system settings. During the execution of a process, at various decision all points personalisation is achievable by using rules that direct decisional flow. Various rule combinations will produce personalised choreographies.

System functions, these take the form of typical OOP function design. System objects and methods describe the system behaviour at an atomic level. The system functionality remains separate from the process, rule and controller level to ensure that there is a layer of separation that can be internally versioned and maintained. Using core development standard and patterns in the system functions will ensure high maintainability of MVCSPR systems.

Returning now to the controller, which traditionally has incorporated the role of the SPR concepts listed above. The role of the controller is to revert to be system scaffolding. The controller is the link between all other aspects of the system as such should not be functionality heavy. Moving functional features away from the controller, the system is less prone to errors during maintenance.

This new paradigm of development is showing highly positive results in the development I am engaged with and leads to highly efficient and agile product development. The next step for me to look into is the separation if system functions between the critical and non-critical; though that I believe is merely preference.

With this new paradigm I believe we will be coming ever closer to a cheap maintainable system designs.

A nicer magazine style version of this article is at