21 March 2019
Symfony vs Zend Framework – PHP Framework comparison Part I: Documentation
Symfony and Zend Framework are two major PHP frameworks, used by PHP developers all over the world to create high-performance web applications using the MVC pattern. But while they both enjoy popularity, they are distinctively different in terms of approaches and solutions they employ, performance as well as their advantages and disadvantages. Let’s go over various aspects of Symfony and Zend Framework. For starters, I’m going to tackle the documentation.
My experience with Symfony and Zend Framework
Symfony has been my first-choice framework for over 5 years. As much as I enjoy it, it was Zend Framework that first allowed me to work in the MVC architecture. In total, I spent a couple of years with ZF2 (from one of the first beta releases). I have to say that I wondered how Zend Framework would feel to me now, after I dedicated so much of my recent time almost exclusively to Symfony.
To make a fair comparison, I will go through all major aspects of both Symfony and Zend Framework. Let’s start with documentation.
I – Framework setup for Symfony and Zend
In both the Symfony and ZF documentation, Composer is used for the installation process and PHP built-in server is recommended as the quickest way to start developing with any of the frameworks. But the docs go on to describe more approaches.
The Symfony documentation suggests you use the Symfony console commands for that, while the docs for ZF mentions php -S directly. It’s worth pointing out that the ZF Framework’s Getting Started part is a step-by-step tutorial about the development process of a simple web application. Symfony’s docs is more elaborate when it comes to explaining various aspects and possibilities, but it seems to be missing a sample application, which explains basic concepts in a consistent way.
For code organization, Zend Framework uses „modules”. Symfony has a similar concept named „bundles”. However, starting from Symfony 4, the docs recommends a „bundle-less applications” approach. Previously, single AppBundle was promoted as a best practice. Personally, I’m not a fan of modules/bundles. I have seen way too many applications, which suffered as a result of the fact that their devs simply didn’t manage to keep modules/bundles independent from each other.
The Symfony docs is elaborate, but it’s not always very practical
II – Routing and Controllers in Zend and Symfony docs
This is the moment, when you really learn what frameworks are all about and their basic concepts begin to surface.
Once you read the chapter “Creating pages” of the Symfony documentation, you are ready to create a really simple, but fully working page that displays a random number. The chapter describes essentials of routing, controllers and templating. It also links to subsequent chapters, where you can get more detailed knowledge for each of these topics.
At the beginning, the docs introduces the YAML format for routing configuration. In later parts, it points out that annotations are recommended for routing. This is a topic that often leads to flame wars. Personally, I don’t see any benefits of not using annotations at this moment. Perhaps, you potentially have it easier to look for defined routes, if defined in one file, but you can also use the Symfony console to list defined routes so it’s a really weak argument.
On the other hand, the Zend Framework documentation shows how to create routing and controllers for an example application – a very practical approach. At the end of the chapter, you know where to create empty template files, but you still can’t see any effects of your work. Routing configuration showed in the documentation is tightly coupled with controller and action names. For some applications, a convention like this may be quite useful. However, in most cases, it may be restrictive. At this point, the docs shows only one approach for routing configuration – a PHP array stored in one file with the configuration of controllers and paths to view files.
III – Database and Models by documentation
The “Databases and models” chapter of the Zend Framework documentation introduces the concept of Models and Table Data Gateway pattern. The ZF example application uses SQLite as the database engine. As far as I’m concerned, it’s a good choice. It limits potential problems with the configuration and helps focus on writing actual PHP code. I’m positively surprised with the practice of injecting framework dependency (TableGatewayInterface), instead of class inheritance shown in the implementation of AlbumTable.
Service configuration is, again, added to the same class as previous configurations, in the form of anonymous php functions. At the very least, this time you are informed that instead of anonymous functions, you may use standalone classes.
Subsequently, you learn how to change controller and its configuration in order to inject newly created AlbumTable. This as the moment I realized just how awesome Symfony’s autowiring feature is.
We also get a first look at the template file. Zend Framework uses PHP as templating engine by default. It’s very powerful but it also allows inexperienced developers to implement business logic on the view layer. It might also be at times difficult to understand for template designers.
See also: How to TDD your MVP?
IV – Forms in Symfony/Zend documentation
The last part of the Zend Framework docs introduces form processing and validation. Building forms in ZF is a little bit simpler than in Symfony, but I still prefer the Symfony way. ZF promotes the add method, which accepts an array as an argument. Of course, it would be very hard or even nearly impossible to design a nice and simple interface for building forms because of how many different types of input fields there are. Still, the name and type should be provided as separate arguments, like they are in Symfony Forms.
For validation, the Zend\InputFilter component is used. It proved even less enjoyable than the previous solution. I’m an opponent of defining validation rules as annotations, promoted by the Symfony documentation. But the ZF docs makes me want to scream, because it’s necessary to implement some interface methods and build validation rules using PHP arrays. It makes it practically impossible to completely keep the business logic out of the framework code.
Using forms in the controller requires some boilerplate code, like setInputFilter() and setData() methods. In the section about editing existing data I realized that a functionality similar to Symfony’s ParamConverters is missing in ZF (or at least it is not introduced in this part of documentation). As a result, developers need to get params from route and find data in the database manually.
If you have seen how Twig templates work with Symfony Forms, you will agree with me that the approach shown in the ZF documentation is very overwhelming. I guess it’s partly the result of using PHP as templating engine. Still, the requirement of setting HTML attributes of input fields at the top of the template file is something I can’t stand.
Symfony vs Zend documentation – summary
While we can’t judge framework by its documentation, I have to say that I like „Getting Started with Zend Framework” for its consistent examples that show basic concepts of the framework.
I’m a bit disappointed with the Symfony documentation. It sure has a lot of details but it’s hard to find information needed to build an actual working application in it. However, the ZF docs made me worried with some aspects of the framework’s architecture, including (but not limited to) form building and validation. Perhaps, I’m simply not experienced enough with ZF to know all there is to solving these seemingly common problems.
I think that it is worth it to mention that Zend Framework provides a lot of components that are missing in Symfony. It includes common aspects of web applications such as pagination as well as some more peculiar ones (e.g. Barcode).
Still, I have to say that to me, personally, the winner of this round has to be Symfony. However, I have to note that I’m planning to take an even deeper look into some specific components of both frameworks. Perhaps, the next time it will be Zend Framework that will emerge victorious?