An MVC Framework
An MVC Framework
... the code is more what you'd call "guidelines" than actual rules.
  — Captain Barbossa Pirates of the Caribbean: The Curse of the Black Pearl


After seeing the Ruby on Rails debut, I thought, "Wouldn't it be great if I had something like that in PHP." Something like it - but with a few tweaks. Actually – a lot of tweaks. Like for starters, scaffolding was the built-in default and by adding content you overloaded the scaffolding. Then there's the Active Record tweaks. I like the idea of Active Record, but why do I even need to be bothered. Why can't the ORM happen without me thinking about it? And what about calculated fields? What about aggregate fields? What about real world SQL? Or NoSQL?

I looked at CakePHP, Zend Framework, and many others. But I was really inspired by this: The-no-framework-PHP-MVC-framework. We've all written or seen similar code before, where every action is its own controller/script. And calls its own view. But it's not really structured and doesn't have any kind of default behavior. So what if we encapsulate it's reusable/redundant code. Give it a default behavior. And fit it into OOD for structure. Yet kept the simplicity.

What I was looking for was a minimalist framework. Something that was lightweight, good default behavior and ridiculously flexible (think "Danger, Will Robinson, Danger"). I wanted something that let me program in the abstract while exposing all the nitty gritty details if I should so choose to tweak them. And let me just tweak, rather than rewriting whole functions or objects just to get a subtle change.

And not to be too greedy, but what if it's presence was transparent. So it would process html files and folders just like a No Framework system. That way I could rapidly prototype a site and add in the functionality (business logic and/or persistence) later. How cool would that be?!

What I didn't want was a framework that restricted me in any manner. I, the developer, should have a dependable structure or foundation upon which to build my application and at the same time be able to color outside the lines with ease, without breaking the structure.

Anyway, here's what happened...

I wanted a simple processor. When a Request was made, a Dispatcher would determine what Action would be called, what View was needed and ready the Model. If the Action manipulated the Model and required persistence, then the Action could call a Save() on the Model. Finally, the Response would be rendered by merging the View with the Model. Typically, just variable substitution. That's it. Simple. Very simple.

I made a list of what I actually NEEDED:

  • controller - something to translate a URL into a specific Action and View
  • objects - some place to assemble data segments and predicates/logic/rules/constraints
  • persistence - typically an SQL database
  • presentation - typically an html page with variable substitution

These needs translated into a Dispatcher; a class aptly named "Model" which will contain all working data and business logic; a class named "DB" which will be an interface to the database (in this case an SQL interface, but any interface would do); and an HTML page with embedded PHP tags. It turns out that PHP is actually a Hypertext processor and can perform variable substitution on its own, no scripting engine required. Who'da thunk it?

While this is written in PHP it was written with C++ in mind. So that nearly all code can be easily rewritten in C++. This way, the code can be converted to a C++ CGI server for embedding or improved performance.

Back to Top

© 2012 and beyond Lawrence L Hovind - All Rights Reserved