MVC Architecture and Single Page Interfaces

It seems I always come back to this blog after taking a break. I’m going to try keep this up to date as I begin in finalising my design, the coding of the system and then the implementation into the real-world environment.

The Problem

The project I’ve taken work of is the forumgaming.com web game system. It runs similar to a board game but all from a single interface. This interface makes calls through Javascript (JQuery in this case) to backend PHP files which do the work and connect to the database.

This sounds fine, however over time the code has expanded with no organisation, comments or any kind of documentation. Things are half implemented with variables cluttering up the code all over the place.

Coming from a Java background I like things to be in neat ordered classes which can be extended when required. One of the problems with this is that websites and the programming of websites don’t work like this.

When a class is instantiated in java it is created in the virtual memory and so long as it stays in scope it exists. Web programming to my current knowledge is different, especially with PHP, as the class is instantiated on the server to do a purpose and then goes out of scope.

The Solution

My plan is to strip out everything from the game to and create a framework that all future code can be built off.

Normal MVC however would not work with this due to the fact the game is a single page interface whereas normally each normally indicates a new page. In my variation I am planning to make it so that views are called via AJAX calls from the main interface to do any processing required.

Very little actually is done through the interface except the viewing the of current state of the board (in this case a map) and then requests being sent to the database which update values, such as moving a unit or requesting an alliance with a player.

In a more visual method the MVC architecture looks like the following as standard:

Note: The solid lines represent a direct association and the dashed lines represent an indirect association through an observer pattern for example.

This is how my interpretation of the system will work. It's a little different but not much so. It's different enough so that I'm not using a pre built MVC architecture and instead I'm going to use the ideas of it instead since the bootstrap is going to effectively be my interface. This is how my MVC-SPI should look:

The interfaces will be updated directly from the views however all calls will go through the game interface (the core index) which will route them and update the correct sub-section. This should allow for extensible code while still allowing for the game to run as it currently does.