It was only recently that we published an article about increasing the efficiency of your development with Symfony2 in the context of the history of popular PHP frameworks. Now we revisit the topic of improving your workflow with Symfony2, but this time we focus on the specific features the framework offers that really make it stand out from the crowd.

Efficiency at work is not really about tweaking the development process, but rather about making sure that the customer is satisfied with the final product of your work. There are many ways to increase customer satisfaction. You can make the features more robust than they expected, get the whole job done faster than originally planned or design tests to make sure that the system works as it is supposed to. A satisfied customer is one that will return with another order, willing to pay even more than before. How to make your customer satisfied by increasing your own efficiency? The answer is the all too familiar Symfony2 framework.

Symfony2 is the biggest PHP framework currently available on the market. Its most serious competitor, Zend Framework, got lazy with its 1.X to 2.0 update (in August 2012), failing to include a series of functionalities that made the July 2011 update of Symfony2 more efficient when it comes to coding and maintaining the code. SensioLabs, the company behind the framework, keeps on coming up with new ideas. Its consistency in improving code usability was awarded with $7 million raised for further development of the Symfony ecosystem. With an influx of cash like this, you can’t possibly have doubts that Symfony will only become even better.

Each app written in Symfony revolves around the Bundle. Bundles are packages and each one of them contains an independent module of the app. You can (or at least should be able to most of the time) copy a module like this to another app and make it work seamlessly with it. This approach to development allows you to write code that is extremely reusable. Once written, a separate piece of code can be reused multiple times and further polished. Reusing code makes you look good in the eyes of the customer. Programmers strive to write reusable code mostly so they can save time on future projects. Symfony provides a way to do this, improving the efficiency of your work.

What’s worth noting is that bundles are more than just a tool for a lonesome programmer to play with in their project box. You can use bundles made by others and are freely available online. The truth is that you can find a bundle for just about anything you may want to do in Symfony2.  In August 2014 Javier Eguiluz (Symfony coach at SensioLab) released the list of 30 most popular bundles:

1. FOSUserBundle (60%)
2. FOSRestBundle (30%)
3. KnpMenuBundle (25%)
4. StofDoctrineExtensionsBundle (25%)
5. JMSSerializerBundle (24%)
6. SonataAdminBundle (24%)
7. FOSJsRoutingBundle (23%)
8. LiipImagineBundle (22%)
9. KnpPaginatorBundle (16%)
10. NelmioApiDocBundle (11%)
11. FOSElasticaBundle (11%)
12. HWIOAuthBundle (11%)
13. VichUploaderBundle (10%)
14. RaulFraileLadyBugBundle(9%)
15. KnpSnappyBundle (8%)
16. DoctrineFixturesBundle (8%)
17. WhiteOctoberPagerFantaBundle (8%)
18. DoctrineMigrationsBundle (8%)
19. MopaBootstrapBundle (7%)
20. JMSSecurityExtraBundle (6%)
21. DoctrineBundle (5%)
22. AvalancheImagineBundle (5%)
23. JMSDiExtraBundle (5%)
24. GenemuFormBundle (4%)
25. KnpGaufretteBundle (4%)
26. SncRedisBundle (4%)
27. LexikFormFilterBundle (3%)
28. JMSI18nRoutingBundle (3%)
29. LiuggioExcelBundle (3%)
30. JMSTranslationBundle (3%)

There are of course a lot more bundles available. As I said, for each advanced functionality there is a person that has already done it and is willing to share the code. Luckily though, it’s not all about bundles. Symfony2 gives you far more possibilities for increasing the speed of coding, including Doctrine ORM.

Doctrine is a library designed to cooperate with many databases – regardless of whether you use MySQL, PostgreSQL, Oracle, Sqlite, or all of them at the same time; Doctrine unifies the way databases are accessed and operated on. Since the 2.0 version of Symfony, Doctrine is in fact a family of smaller more specialized libraries. At some point, the authors opted against the idea of a single monolithic database that handles all aspects of database communication. You no longer worry about what engine each of your databases utilizes – Doctrine does it for you. Developers can work on a local MySQL database even if the production server uses PostgreSQL – Doctrine will map the structures and functionalities of each database into independent PHP objects. This allows us (programmers) to avoid the need to learn yet another database engine, going through the rookie phase of common query syntax errors, struggling with table structures and data types again.

Aside of the abstract database layer, Doctrine provides you with an easy to use migration mechanism for table structure and data type changes. Every web developer knows how troublesome syncing table models and entities written in PHP with the real data structure present in the database can be. PHP frameworks come up with various ways to solve the problem, but it is Symfony2 that makes me smile with its solution as I know that it will let me avoid many structure compatibility-related troubles. As a matter of fact, I can’t imagine myself using Symfony2 with a database library other than Doctrine. Its only disadvantage is that it consumes quite a lot of RAM and CPU power. It’s a really big, enormous really, library that works with many database engines and as such you should expect that it consumes more resources than other, less capable, libraries. Ease of use and setup also contribute to the popularity of this ORM solution. The more you use it, the more efficient your work with the library and entire Symfony framework becomes, saving you time and earning consumer satisfaction in the process.

When you work with Symfony, you never have to worry about support in the form of framework updates as SensioLabs and the whole community see to it. Symfony updates are released according to clear guidelines. Those include the LTS (Long Time Support) versions that receive three-year security support instead of the usual one year.

Unless you want to update your Symfony version every year, you can choose the three-year version and use the saved time to make your app more effective. I believe that the LTS version is more beneficial for the customer, as in most cases they can’t tell whether their product will survive in the market for longer than a few years.

Since I already mentioned software development, it’s a good moment to talk about Symfony’s powerful code debugging tool – debugbar.

Thanks to debugbar, the programmer has easy access to all the data involved in the current request: Symfony version; PHP version and extensions; detailed info (visible when you click the topic of the request); controller; action and routing; stats on execution time and RAM consumption of all scripts involved in displaying a given web page; information on view files attached; logged-in user info; and a variety of information related to the connection and database queries made available by Doctrine. All the information is kept safe as debugbar can be reached only in a special environment that is accessible exclusively for developers. No other framework makes it possible. While Zend Framework has an extension that works in a similar fashion, you have to install it and configure it separately, which is a waste of the programmer’s time as something as basic as a toolbar with functions necessary for development should be readily available.

The features described above do not exhaust the long list of things that make your work easier in Symfony2, but I do believe that these are the most important. They really make the Symfony ecosystem stand out from the offering of frameworks available for PHP programmers.

Paraphrasing the slogan of a popular car manufacturer:
Symfony – advancement through efficiency!