 |
| 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.
