Another MVC approach

So, after having read and heard much about the Model/View/Controller pattern, I decided to apply it to a new web application at the office. After much trial and error, redesign, refactoring, and more reading, I've come up with a simple architecture that actually works quite well. If you're not at all familiar with MVC, I suggest you read the wiki page for a brief introduction. Ready?

My application can be broken down into roughly 5 objects: the FrontOffice object, Controllers, Actions, ActionResults and Views.

FrontOffice
The FrontOffice is where the request comes in. Since a request could come in through any kind of protocol, I've defined FrontOffice as an abstract class, extending on it for each protocol. In this case, we'll use the FrontOffice_URL object, to extract the request from the URL. The FrontOffice simply translates passes the request on to the Controller that's responsible for handling the requested Action. This is called a single point of entry.

Controller
I´ve decided to cut the controller in three pieces to allow for more abstraction. The Controller only takes care of the mapping from an action alias to an action class, providing the model, and executing the result.

Action
Action objects deal with authorizing an action (business rules), and executing the action. This is actually an implementation of the Command Pattern. Depending on the outcome of the Action::execute() method, the Action returns a ActionResult object. This determines the routing of the application. For example: if a record is successfully added to the DB, redirect the client to the overview page. Else, show the Add Record page again, and display the error.

ActionResults
ActionResult objects are returned by an Action object to the Controller. They implement a simple interface, that just says that every ActionResult object must have an execute() method. Examples of ActionResult objects are ActionResult_View (present HTML), ActionResult_Redirect (redirect client) and ActionResult_Download (present a file download).

Views
The Views are simple php files that define the html for a page and take some simple data to combine with it.

The diagram below shows how a request is processed by the system.

The Model
So, after seeing this, I can hear you say: where's the model? Good one. THis may come as a surprise, but there's no Model classes in my model. In my opinion, the model should handle basic validation and sanitation rules of your data To achieve this, I use a powerful DB engine, written by my friend Arnold Daniels. It's called QDB and it's available for free on his website. For each of my database tables I have a .ini configuration file (you can use yaml or whatever you prefer) that defines datatype and validation rules (required yes/no, maxlength, validate email etc). So when I need the model in my controller, I just call the QDB library for a record/table/recordset and it gives me the data. You don't have to bother with mysql statements or whatever, it's all taken care of under the hood. So basically, the Controller is ignorant of the type of database you're running on. Check the code examples for the simplicity of QDB.

Now, let's take a look at a simple example.