Symfony vs. CakePHP: My Experience
April 17th, 2007 by Damian HodgkissHaving used CakePHP 9am-5pm for the last year on a large (150+ table) commercial application due to a clients requirements, and using Symfony for other web site applications I decided to write this article to compare my experience using both PHP frameworks concurrently.
I will say straight off the bat I am bias for the Symfony framework, but I have tried to share my experience also being fair to CakePHP where possible. My opinion is that Symfony is a very elegant, flexible framework that I can use in any situation while I feel that CakePHP has many limitations and annoyances in any large application that I find every day.
I find CakePHP’s biggest flaw to be the model layer. If this used an ORM approach much like Propel or Doctrine I believe the data side of CakePHP would be far easier, especially in large scale applications.
Installation
Symfony
Installing Symfony may be performed in two ways. The first using the sandbox allows you to download the framework and develop your application inside the directory structure.
The second way to install Symfony is to globally install the libraries as a PEAR package. This is achieved by adding pear.symfony-project.com to your list of PEAR channels and then performing a pear install symfony/symfony.
You may then use symfony init-project to create as many projects as you like on the same machine.
CakePHP
Installation of CakePHP is done on a per application basis by first downloading the framework, and then developing your application inside the directory structure. This makes getting up and running very fast with the only requirement being to configure your database settings.
Configuration
Symfony
Configuring Symfony may be a rather simple task or a rather complex task depending on your own requirements. Symfony uses .yml text based configuration files which are compiled to PHP files for caching purposes. Basic required configuration only consists of database and routing settings, however there is a host of other optional configuration steps available from configuring meta attributes in your HTML right through to configuring validation attributes. Configuration by also be performed on a per-module basis overriding the default configuration for modules and individual actions.
CakePHP
Configuration of CakePHP is rather simple, with the only requirements being to configure the database settings and the routing configuration. All of the main configuration is done via core.php which has a few other settings but most users will not need to touch these.
Views
Symfony
Symfony views are basically raw PHP template files with variables exposed via the action. You are provided with a large amount of default helpers allowing you to perform Javascript and Form operations with ease.
CakePHP
CakePHP views also uses raw PHP template files with variables exposed via the actions. As with Symfony, CakePHP templates also support a large amount of default helpers, with the main difference being they are object based instead of function based.
Models
Symfony
By default Symfony uses a third party ORM known as Propel for its model layer. The configuration for Propel works by defining your schema in an XML (or .yml) configuration file which defines the entire database including all of the tables and foreign key relationships.
The advantage of this method is each model then has a class generated for it, which you may extend with your own functions providing a great data object based environment. SQL for the engine of your choice is also generated, and optionally loaded in to the database server for you.
CakePHP
CakePHP tackles models in a completely different way, by defining your models (tables) in classes. Each class is then not used as an object, but instead returns an array of data. I really dislike this method of data modelling, as the data returned is far too static for my liking often consuming vasts amounts of RAM when used recursively. I believe CakePHP version 2 will use objects, I am unsure what affect this will have on porting existing applications.
If you enable DEBUG 2 in your configuration file you will also notice that CakePHP issues a DESC table command on each request to discover the database structure dynamically. While it does support caching the data, against I am not fond of this method at all with a lot of queries being performed on each request.
Validation
Symfony
Symfony uses form validation which is performed against the GET and POST parameters submitted in the request. The validate.yml configuration file is a flexible configuration file allowing you to specify what parameters are required, what error message to display and what validator to use along with any parameters to pass to the validator.
CakePHP
The CakePHP approach to validation is in the form of a $validate array in each of the modules. Validation is performed on each of the fields when you attempt to save data to the model. The validation is rather simplistic allowing you to check each field against a regular expression pattern.
Routing
Symfony
Routing in Symfony is performed by modifying the routing.yml configuration file. You may define unlimited routing rules which use regular expression to match URL paths which point to modules and actions. You may also use :parameters to pass in to actions also supporting default values.
CakePHP
Routing in CakePHP is performed by modifying the routes.php configuration file. CakePHP also supports defining unlimited routing rules using the $Route->connect() function which also use regular expression to match URL paths which point to a controller and action.
Debugging
Symfony
Symfony debugging is performed by enabling the debug option in the application settings.yml configuration file. By default, you are given a production, test and development version of your application and this is automatically done for you in the development version.
Provided you have setup the Apache configuration properly so the /sf alias is able to access the Prototype Javascript Library you are presented with an attractive overlay debug panel at the top of your screen allowing you to view all aspects of the request including routing, template and SQL query information.
CakePHP
CakePHP debugging is performed by enabling the DEBUG define in config.php, by changing it to an integer value of either 1 or 2.
Changing this to a value of 1 will force CakePHP to print results of debug() and pr() calls to the screen, while changing this value to 2 will force CakePHP to also display a dump of all the SQL queries performed at the end of the page request.
Plugins
Symfony
Symfony has a vast amount of plugins available at their plugin repository including Javascript library integration, Propel extensions, model layer replacements and security. Some of my favourite plugins include sfFeed2Plugin, sfShoppingCartPlugin, sfGuardPlugin and sfSslRequirementPlugin.
CakePHP
The CakePHP framework does support plugins with its repository located at CakeForge. However the CakeBakery seems to be the place for a large supply of usable extensions. Some that grab my attention include SwiftMailer, Yahoo Geo Coding, Report Creator and the jQuery Helper.
Posted in Development | 
April 18th, 2007 at 5:47 pm
Well, plugins are only one way to extend CakePHP, you can also write helpers or components (plus behaviors in cake 1.2). And beside CakeForge there exists also the bakery (http://bakery.cakephp.org) where you can download such helpers and components.
Btw: The main config file in cake is called core.php, and not config.php.
April 19th, 2007 at 11:28 am
Thanks, corrected the configuration option.
I chose not to go in to too much detail on helpers and components in the views section of which CakePHP and Symfony both support.
The plugins comparison was more trying to compare the available list of third party plugins available, I see CakeBakery has quite a few useful ones so I will add the URL.
May 1st, 2007 at 11:19 am
Nice little review. Thanks!
July 5th, 2007 at 3:14 pm
Interesting review. Thanks for sharing.
As far as I see it, it’s all coming down to the developer’s choice. Not a very big difference between the 2 frameworks.
I for one like cakephp, for it’s easier to configure and faster to develop.
July 5th, 2007 at 3:28 pm
Well I think the only real similarities in the two frameworks is they both implement MVC patterns in their own way but in the ways everything is implemented there are huge differences.
CakePHP implements OOP in a very basic way while Symfony (which ofcourse is only supported on PHP 5) takes full advantage of OOP patterns (again, due to PHP 5) mimicking how you would implement a framework in a language like C++ or Java.
July 14th, 2007 at 11:28 pm
Cake is very appealing and I’ve been recommending it recently to people, but as the author says, one of the big and somewhat surprising defficiencies is the model layer. Whilst the developers have definitely done a great job so far, it feels as though they may not have fully understand about OO modelling when starting out.
However, as there are callbacks such as afterFind() and also behaviours, it’s possible to implement mechanisms now that will embed the array based row data in a lightweight secondary model object that then provides access to the data via members or methods and where additional functionality and value can be added in the true OO way. beforeSave() can similarly be used to export the data back to an array form before saving. However unless the row based data is also available in views, the provided form helper is essentially unusable because of the expectation of the presence of array based data, and so the limitations aren’t entirely trivially, or efficiently, dealt with.
Cake is still very enjoyable though.
March 10th, 2008 at 4:03 am
One of the shifts that Symfony has made is to Doctrine, which I’ve been using in isolation; like Propel it pre-creates empty model classes that you can fudge with. Doctrine can return data in heirarhical arrays or object arrays and works nicely with memcache. However I would like to point out that there is a semi-OO way to treat records in Cake; the same model classes you use to pull data arrays from can be treated themselves as record objects for the purposes of specializing save behavior.
The philosophy behind the Cake approach is that “Data is stupid”: the structures that enmesh it is where complex logic belongs, not the ORM layer which should simply fetch and update information. If you want an object orientated representation of a business concept in Cake, you’d write a factory component that uses the ORM to initiate it. The presumption, which is often very well justified, is that a huge number of data silos do not require that level of sophistication, and a quick and simple array retrieval engine is sufficient.