Home » PHP » PHP MVC Frameworks » Writing a Fast PHP MVC Framework – Part 1

Writing a Fast PHP MVC Framework – Part 1

Well, after tossing and turning and considering using Yii and CodeIgniter, I’ve decided to bite the bullet and write my own fast PHP MVC Framework, that’s not bloated with features or compatibility layers I don’t want and takes advantage of PHP5.  Why re-invent the wheel you ask?  Because in my view what’s current out there is bloated and not quite what I want and most importantly ultimately impacts performance, which I very much about.  This framework that I’m writing is going to focus on speed and keeping ways to do something to an absolute minimum and do only what’s required.  For example, Yii is hell-bent on using ActiveRecord for everything and if you look at the code for active record with it’s built in ORM it’s like 2000 lines of code to generate SQL that you can write yourself just as easily.  With or without opcode caching lots and lots of code, lots and lots of files and all the un-necessary logic is still going to slow things down.  In CI’s care it’s nice and all, but it doesn’t play nicely with PHP IDEs atm so you better know the classes and methods pretty well.  Also, I can’t say I see the reason for doing things like defining file extentions (i.e. .php) as a constant, implementing fancy stuff like :any in the router and so on… just un-necessary logic… but as I said the biggest issue is not playing nice with PHP IDEs like NetBeans and Eclipse PDT.  The closest thing I’ve found to what I like has been what Daniel’s implemented in OpenCart which is somewhat based on PHP Pro MVC tutorial.  So to get started…

OK, the first thing is to define some of the absolute core components that will be needed by this PHP MVC Framework…

  • MVC – Well this one’s obvious, it’s not much of an MVC framework without MVC.  For newbies, MVC is just a nice way to achieve separation of presentation and business logic.  In this case we’ll use Front Controller… i.e. All requests will be piped through a single entry point index.php and routed within that.  There’s a bit of thinking to go in here how to make it work well hierarchically so that we can have portlets, widgets, modules or whatever the name we choose for them.
  • URL Routing – It’s extremely important to have good SEO these days, so this is high on the list.  This is going to be purely regex based, if you don’t know how to use regex you should learn.  I’ll decide of whether to use straight mod_rewrite or do it inside PHP when I come to it, both have pros and cons.  There is also a need to both convert from SEO urls to internal structure and vice versa.
  • Registry – We’re going to be passing around a lot of stuff and rather than defining it all in the global scope it’s best to pass it around in the registry.
  • Logging – Need to be able to capture what’s going on in our application.  We may want to log to a file or a database, but rarely are we going to do both, so we’ll work out how to best achieve this…
  • Configuration – We need to have a way to provide configuration information for our application, can’t do much without it.
  • Request/Reponse – We want to be able to handle HTTP well.  Also I find that I use fragments quite a lot for SEO so we want to be able to have access to all the SERVER, GET, POST, COOKIE, REQUEST, FILE and FRAGMENT variables from a single place and be able to output data in a consistent way too.
  • Session Management – We need to be able to handle session management, we will also need to think how to handle different ways of storing session data, as like with logs we’ll tend to use one but not all.
  • Database – I’m only using MySQL so I can just stick to implementing a mysqli based class to do everything I need.  This is pretty important too as pretty much any app is going to be HTML based.
  • Pagination/Paging – Can’t create any serious application without Pagination.
  • Html Output – Need a consistent way to generate forms and other Html output, so this is pretty much a must.
  • Email – Pretty much any reasonable website is going to need to send emails and they’ll probably have to be via SMTP and in HTML format, so this is a must as well.  It would be real handy to have some templating capabilities too.  There are lots of good email libraries around so may as well use those where possible, as email isn’t the simplest thing to implement and there’s no need to re-invent the wheel as it’s not like you’re sending an email every couple of seconds, so it’s not going to impact performance too much.
  • Captcha – Gonna need something to do combat all that spam
  • Form Validation – Need a consistent and easy to use way to perform form validation.  This will generally need to be both client-side and server-side, so need to rely on a javascript.  In my case jQuery is the chosen one.  Also it’s best not to have to write the code twice obviously.
  • Helpers – Will definitely need a few Helpers (i.e. Static Classes with Static Methods) to do stuff like trim text, manipulate Arrays, Paths, etc, etc.
  • Caching – This isn’t something that will be needed straight away but at some stage there will be a need to cache output or potentially parts of it such as some module/widget/portlet output.
  • Breadcrumb – Pretty much any decent website is going to have a breadcrumb so better write one.
  • Encryption – Need to be able to encrypt passwords, so need something at least basic to do this.
  • JSON – Pretty much going to need something if we’re going to write Web 2.0 apps that use JSON, so better add it.
  • HttpClient – Most libraries dont’ seem to have a decent HttpClient but if you’re going to make any requests to third-party websites or do scraping/crawling this is a must.
  • Hook/Event Mechanism – This is something that may be required to keep the library code separate from the application code, with hooks getting called / events getting raised (same thing) at pre-defined stages in the page lifecycle.  If adding calls as required directly into the library isn’t too big a deal then there’s no need for this.
  • Minification/Optimisation – For production code I don’t think there’s any reason to force PHP to parse all the comments within the framework so there needs to be a little tool that allows all the comments to be stripped off.  Comments are needed for code completion in the IDEs, but slow down performance (although minimally) because the files are bigger and need to be read in by PHP for parsing.  All classes that are used in every request can also be aggregated into a single file with optimisation so that there’s no need to load them in individually, which once again improves performance on servers with no opcode caching.
  • Translation – Personally I don’t think I’ll be writing anything that requires multi-lingual support anytime soon, but it’s something that should be there.

Well, I think that’s pretty much what you need for a functional framework… I’ve spent about half an hour looking for other stuff I think you might need in Yii, CodeIgniter, Kohana, PrestaShop, OpenCart, ASP.NET and ASP.NET MVC and I think I’ve pretty much covered all the important bits that would make up a fully functional framework.  One thing to note is that it doesn’t really matter if you’re coding in PHP or .NET those components are pretty much a requirement for any fully featured framework.  In ASP.NET for example many of these features are already implemented as it’s a higher level framework than barebones PHP, but you still need to implement some aspects, such as pagination, email templates, data access, email, captcha, encryption, breadcrumb and a few other minor things.  However, .NET including both ASP.NET Forms and ASP.NET MVC also comes with a bit of baggage.  For example ASP.NET Forms makes doing any client side stuff a real pain, while ASP.NET MVC doesn’t have some basic stuff like Pagination.  Yii and CodeIgniter implement most of these aspects already, but as I said the problem with Yii is that it overcomplicates things and forces ActiveRecord and ORM onto you and that means learning the Yii ways of doing things and writing queries rather than writing a little SQL to do the same in half the time and without the un-necessary compexity and performance hits, while CodeIgniter doesn’t support code completion in IDEs, which is also a massive timesaver.  Both Yii and CodeIgniter have lots of extensions and plug-ins to fill the gap for stuff that really should be in the core framework, but with both I found that the quality of the plug-ins isn’t quite as good as the framework and for CodeIgniter in particular many of the extensions are half baked examples on the forums rather than code that just works.

I don’t think that writing this framework will be too difficult as I’ll be writing it as part of writing an actual application that I need to write anyway and for which I was evaluating all the different frameworks in the first place.  Also there are plenty of good examples all around including Yii, CodeIgniter, Kohana, OpenCart, Solar and plenty of others.  The main idea behind this PHP MVC Framework though is to make it lightweight and easy to use, while leveraging PHP5 features and supporting IDE Code Completion.  To be honest I’m rather surprised that nobody has already written a framework like this, or at least hasn’t published one as open source and every man and his dog seems to have jumped on the ORM and ActiveRecord bandwagon.  It’s a real shame people don’t understand that for most datacentric applications, especially with a big database and some data compexity, where it may be split between multiple tables, ActiveRecord just doesn’t cut it.  In Martin Fowler speak, you really need to either use DataMapper if you’re working with pure OO Domain Model or TableModule with TableGateway.  In my experience of over 5 years writing both .NET and PHP, TableModule with TableGateway is by far the most appropriate as it nicely manages quite compex applications, both in terms of data and logic and doesn’t make you work at high level of granularity like you’re forced to do when using pure OO.  For example, when I want to just updated a single customer field or retrieve a single customer field or perhaps some aggregated data of such as orders with the customer name, OO tends to encourage you to fetch or update the entire record or even worse list of records, when this is simple not necessary. Anway, rank over, will start on the framework tomorrow.

Share
Categories: PHP MVC Frameworks Tags:
  1. June 2nd, 2010 at 01:50 | #1

    G’Day,

    Just wanted to know whether this tutorial was still being worked on?

  2. June 2nd, 2010 at 02:50 | #2

    Yes, I have started on it, but I’m finding that Yii Framework seems to already do much of what needs to be implemented and does it pretty well. At the moment rather than re-inventing the wheel I am trying things with Yii Framework first to see how it performs. Performance would certainly be better with a custom framework, but a custom framework also requires a fair bit of work and determining exactly how to implement certain aspects, so it’s not something that can be developed quickly.

  3. June 11th, 2010 at 16:31 | #3

    I personally use Yii for a lot of my projects. But the Lithium guys really have it dialed in as far as a modular and light-weight PHP framework is concerned.

    I saw them speak at Tek this year and was really impressed.

    http://lithify.me/

  4. June 13th, 2010 at 07:35 | #4

    Yeah, I had a look at Lithium, it seems alright, but it’s for PHP 5.3+, which means it won’t run on MANY environments at this stage. Also, from a maturity and community perspective I don’t think it’s quite up there with Yii.

  5. Sam
    August 20th, 2010 at 13:16 | #5

    Have you made any progress on writing this yet? Would be interested to know if you have.

  6. August 21st, 2010 at 02:27 | #6

    Well, I actually decided that rather than re-inventing the wheel we’ll stick with using Yii Framework. The reason for this is when I started writing my own framework I found that I was doing things in a very similar way that Yii has already done them… I mean sure, I don’t like Active Record or ORM, but it’s easy not to use them in Yii, but the rest of the stuff is pretty much how I would write it anyway. Basically the slight performance advantage and perhaps some simplicity you would gain from writing your own isn’t worth the effort when there is already something there that can be easily used. More importantly with Yii Framework I can hire staff and also outsource the work to people who are already familiar with Yii Framework! So basically, as good of an idea as it is to write your own, I don’t think in 99% of case it’s really worth it. I’d love to do it, but the amount of effort is pretty huge. So for now my suggestion is use Yii Framework or CI or Kohana.

  7. January 29th, 2011 at 03:32 | #7

    It looks like every person who came to idea of using framework in his regular work and faced the bloatness/slowness of existing ones decides to create a lightweight flexible mvc framework himself :-)

    I’d recommend to look at these links, maybe they will provide you (or proof your) ideas on building it:

    http://www.phpro.org/tutorials/Model-View-Controller-MVC.html
    http://sevenkevins.com/

    You’ll see the same set of tasks are set there: mvc approach, basic database abstraction, template engine, logging, etc.

  8. December 12th, 2011 at 16:10 | #8

    Hi guys ,
    I recently wrote a MVC framework , and I did that because of the same reasons.
    and the extra reasons where that I don’t like looking under the hood of other frameworks … mainly because there is a lot of code that you should go through before understanding it how it works.

    I already wrote a whole project using the framework , and it looks like it suits my needs ,
    speed vs organisation vs simplicity

    And what is best from all , I know the code , and if something goes wrong I know where to look at.

    I have’t published the code yet , I’m looking to place the code on git hub…. so it will be open source very soon

  1. No trackbacks yet.


7 − one =