MVCxN pattern

Model-View-Controller (MVC) is really a nice design pattern, but as an application becomes bigger the MVC pattern looses structure, in the sense that it becomes time consuming to find things.

2 days ago I created a fork of MVC: MVCxN. The basic extension is: If you have N components, then every component will have its own local MVC structure. Why is this useful? Because this approach creates very high coherence in your application structure! Let me tell you how I used it...

Skeletonz's internal plugins

Upload was an internal Skeletonz plugin. Code for uploading was spread in the MVC structure and it was very hard to fix bugs or to learn the structure since things could be found in following files:

• skeletonz/Site.py - The controller was located here
• skeletonz/server.py - The controller was tied to amiweb in here
• skeletonz/model/CMSModel.py - The model was here
• skeletonz/static/scripts/editable_components/Upload.js - JavaScript code was located here
• skeletonz/modules/template.py - Upload.js was added here
• etc...!

Basically, the coherence is pretty loose and finding upload parts took time and effort (especially if one didn't know the system). Skeletonz has around 14 plugins, so you can imagine the mess it would create...

A normal MVC pattern is great for small systems or small sites, but as the application grows I really recommend moving to MVCxN architecture.

Using MVCxN

MVCxN takes time and effort to code. But this is what it provides: Upload model, controller, view, JavaScript files, images etc. are located in one directory, namely:

• skeletonz/plugins/upload/

If there's a bug in upload, then you only look in one directory. If you want to extend uploading with a new feature, you also do this from one directory.