Our Company has been in the process of evaluating the Symfony Framework for PHP. We have written several projects using the framework some small and some larger. In this post I intend to layout some of pluses and drawbacks of this particular PHP Framwork. (its worth noting that we tested using version 1.4 with Doctrine.)
The Good:
- Symfony routing is amazing. The ability to change urls at will without adjusting links is wonderful. The flexibility allows for much more meaningful and useful urls. It makes for shorter and easier to remember urls.
- Symfony makes adding new programmers to a team easier. By enforcing a system of common organization, it allows a new programmer to quickly find code and understand the flow of a program.
- Symfony cache speeds up page loads. The caching system built into the Symfony Framework is quite flexible allowing you to define which pages (or even parts of pages) are cached and which ones should be generated every time.
- Doctrine makes database interaction easy: Doctrine allows you to ignore the database and just deal with objects. It takes care of mapping objects to records for you. This removes coding time and error potential.
- Symfony provides a great system of code reuse. Through the use of partials, templates, filters,and helpers, the Symfony Framework provides a structured way to re-factor not only php code but also html snippets.
The Bad:
- Doctrine is slow. For a database with ajust a few records, Doctrine is wonderful, but if you are dealing with a 100+ records, Doctrine feels like riding a Tortoise on a state highway. Some of this is made up for by the cache system, but there is no good reason for the degree to which Doctrine slows down code execution.
- Symfony Forms are a pain. Although they can often just be dropped in, trying to customize and extend forms can be a real headache.
- Symfony has way too many folders. Organization is great, but really?
Overall, I would cautiously recommend the Symfony Framework for PHP. If you are doing a small project, its probably not worth the effort, and if scalability and speed are big issues, you will want to avoid Doctrine. However, if you are doing a medium scale project where caching is acceptable, Symfony may just be the PHP framework you need.
Just came across your post on symfony, and thought i wanted to share a few points.
ORM BENCHMARKS
There is a great benchmark of Doctrine and Propel on propelorm’s blog. Which gives great figures about what’s fast and slow. I believe it also depends on how you make your queries. Our experience with ORM’s and performance is fair, compared to what you get in return. Not sure what kind of response time you are looking for.
http://propel.posterous.com/propel-16-is-faster-than-ever
A FEW COMMENTS ON THE DOWNSIDES OF SYMFONY
Since the early version of Symfony we have used it for several projects, and sticked with it. And many things has changed throughout the time.. i believe it was once a decision taken by the Sensio that it should be less “magic” and automatic and rather more flexible. So it was more dynamic and could fit almost any given project, especially with their v2.
I agree having a team, jumping blindly into a symfony project is not always that easy.. and also i know of many people giving up, before they really understand and get the full benefits squeezed out of symfony. The learning curve is rather high, compared with other frameworks out there.
We actually developed our own extension on top of symfony to simplify development in our teams. The end results was a complete visual application builder, which almost automates the entire development cycle. While still leaving room for customization at the symfony level Which abstracts some of the downsides of symfony, but again i guess all benefits has disadvantages. AppFlower (http://appflower.com) is great for data-driven business applications, if you want a Sencha like user interface..
Curious to know your test-results on Doctrine..
It looks like Doctrine 2.0 has some decent speedup improvements. However, our current project is based upon symfony 1.4 which is stuck with an older version of Doctrine. With future projects I will probably plan on using Symfony 2 with Doctrine 2
Do you really need a database abstraction layer ? If you do create a software that you do not know on what database it will run (like CMSs, forums, blog engine) then you need DBAL. If it’s for a website you know what the database will be and you know you will be using the same database in development and in production, why cuting yourself from using the nice features and performances a SQL engine can propose ?
You are correct in stating performance as a downside of DBALs. Using Doctrine is a choice I have second guessed several times. It ends up being a trade off between the ease of programming and performance. Using the Doctrine support provided through Symfony saves a lot of programming time and eliminates many bugs. However, at least before Doctrine2, it comes with a pretty heavy performance hit. If it wasn’t for Symfony’s caching algorithm, I would avoid Doctrine for certain queries, but the caching engine has made Doctrine’s performance acceptable. Again, its a trade off; if I need performance I would avoid Doctrine, but when I just want to accomplish a task quickly and without much debugging, Doctrine is useful.