Application Structure

With the addition of galleries and the increased complication of the database structure, the ‘whatever works’ style of development I’d used during my initial proof of concept prototype was beginning to create large problems. The application was built around a central idehandler.js file containing the logic for the editor and asynchronous editing and handled snippet data once loaded from the database which, at the time, comprised almost the entire functionality of the application. In order to clean up the maze of spaghetti code I’d created by allowing my “Let’s just get a prototype working” mindset to persist for too long, I decided to adopt the MVC pattern.

The Model-View-Controller pattern is involves three areas which are, unsurprisingly;
Model: Stores the state of the application.
View: Generates output for the user.
Controller: Handles the logic for the application and updates the model and view.

By using this structure code can be kept as clean and intelligible as possible by splitting functionality into the data stored, the operations which handle the majority of that feature and the interface that is displayed to the user. Having separate models, views and controllers for each feature(e.i. one for the gallery and one for the editor) further increases code clarity.

This choice stemmed from the fact that with the exception of a few fatal blunders, I’d already been building to vaguely this pattern in that I had jade to handle my views, idehandler.js as my one and only controller (But also partially performing the job of the model) and a database.js module trying to act as the model but not actually holding any of the application data itself after loading it from the database.

The main structure of the application is comprised of;

app.js
This is the main file used to create an instance of the server module to start the application. It also loads the model, controller and router modules. The reason this is handled at the highest level of the application is so that they can be passed throughout the application and accessed through a variable rather than having to load them multiple times later during execution. This means that wherever a module is accessed in the application it will have the same state, rather than, for example, creating a separate instances of the snippet model for the IDE and the gallery page which have no knowledge of one another. This method also means that if the directory structure of the application changes, there is only one place the file paths have to be modified.

server.js
This module initializes and stores instances of the http server, websocket server, database connection, initializes the controllers and passes them references to access one another.

router.js
The router handles incoming connections, reads the url, directs them to their appropriate controllers and then renders the Jade templates and sends them to the client.

Controllers
Each primary feature will have a controller to handle the main logic. The controller will retrieve the data from the model modules and process it as required.

Models
Will retrieve data from MongoDB, handle data-related tasks such as adding/removing entries and store snippets which are currently active and being used by the IDE in order to reduce requests to the database.

By using this pattern, I hope to increase the scalability of my project and reduce the amount of time required to add new features later on.