If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

When I first started programming my dating website, I started working from scratch, using all original PHP code along with custom MySQL databases and table structures. I got pretty far, but I soon realized how difficult things were going to become with regards to maintenance and expanding.

I began tinkering with a couple of frameworks. The first was CodeIgniter. It offered a nice separation of code, utilizing the MVC methodology. It included a database access class, but I found it to be cumbersome with an undeniable learning curve. I prefered the use of pure SQL over the implemented database functionality.

I also learned that there were issues with the way in which the code allowed access to models — the M in MVC. In order to utilizes custom classes, they had to be filed within the “model” folder of the project. In turn, the class would have to be accessed as a model. Unfortunately, in order to access models, an instance of a class must be created even if the class is not intended to be used as an instance class. I had a number of pre-existing classes I wrote using the Singleton pattern, meaning that there was no public constructor. This caused me some headaches, and I quickly decided to abandon this framework.

A friend directed me to PHP on TRAX and Symfony. I first took a look at PHP on TRAX since it is a framework I previously heard of (but forgot about). It offered solutions to the issues I had with CodeIgnitor, which initially gave me some greater hope. It also included an ORM (Object-Record Mapper, usually an implementation of ActiveRecord), which looked to make coding around database access simplified in the long run. However, it had a bit of a learning curve with regards to setting up each class to work correctly with the database structure, which I did not mind learning for the benefit I would have in the long-run.

I decided to discontinue working with PHP on TRAX for several reasons. First, the documentation is rather sparse. A lot of hacking and digging into code would be required to find out exactly how to access and utilize much of the framework. Because I want my dating site to be easy to modify and work with in the future, I do not want to utilize a framework that lacks any amount of documentation much like this one does.

I also found that PHP on TRAX was lacking any sort of built-in caching, which is going to be a big concern for a project as large as this. I eventually expect to have a relatively large member base, and so I’ll definitely need to cut processing time with caching.

I also took a look at Symfony, though I did not test it like I did with the previous two frameworks. From what I have read, however, it does not appear to be as simple as many of the other available options.

Today I decided to look into CakePHP. I heard of this before, but I never looked into it. As it turns out, it appears to have the answers to my issues from above. It includes of view/page caching as well as an easy to use database interface. It even offers solutions for AJAX implementation, which I intend to use.

It looks like I’ve found what I’m looking for, but if it turns out that I run into serious problems with this framework, I know there are still options. Just to name a few, here are others that I haven’t really read up on in detail:

• Zend Framework
• Seagull Framework
• Web Application Component Toolkit
• Prado
• ZooP Framework
• Qcodo
• Akelos Framework
• Solar for PHP
• Achievo ATK Application Framework
• FreeEnergy