When I first encountered the Zend Framework I was blind-sighted by the high level of abstraction, the clean code and the rich library. I was 18 years old then, and my OOP knowledge was limited to developing simple websites that utilized a couple of classes + Smarty. In theory, I knew everything about OOP but I had no conceptual idea how to take advantage of the power of this technology – I had only heard using classes and objects was cool. Zend Framework has played a major role in my professional development and has managed to completely shift my worldview, transforming my then idea of coding into something quite different. Zend Framework has taught me to think object-oriented.
Every coder, who is familiar with OOP in theory (but not, for instance, with design patterns), has the illusion that they have no need for community-wide approaches, that they are great and have no need to learn from anyone else. This is what I see in almost every PHP coder nowadays. Before I came across ZF, I too was a bone-headed beginner.
Let me describe а project which does not utilize a framework: it has a single class, often named either Main or Core, and contains various methods – from database connections to product information retrieval, to as far as user registration. This is the Mothership. It is thus often the case that the Mothership includes over 10,000 lines of code, and is the author’s ultimate pride. Some programmers measure their… lines of code, but in the source code, quantity != quality.
The transition from this obsolete style to object-oriented thinking can be very difficult (utilizing a couple of classes does not make your project object-oriented but rather an object-disoriented one).
When I found out a year ago that a new version of my favorite platform was under way, I was more than sure that there’d be a ton of new stuff to learn and I had the feeling that Zend was going to change the world of PHP once again.
So, what was wrong with Zend Framework 1?
Although I have very sentimental feelings toward ZF, I cannot ignore the fact that there are a lot of things in it that I dislike.
A clumsy module system
The module system inside Zend Framework was added at a later time. In earlier ZF versions no attention had been paid to modules, which meant that the module option was fitted in afterwards. Many important options had been omitted such as module configuration and a configured classes-loader. All these things were not that difficult to mend but they did get on people’s nerves.
Too many Singletons
One of the platform’s most common design patterns is the Singleton. But what makes the Singleton bad? It is so easy to implement and utilize. The truth is, the time of singletons has passed and we ought to gradually forget about them.
What makes the Singleton bad?
Let’s take, for example, Zend_Controller_Front – the backbone of the MVC implementation in Zend. This class provides a single object in the entire application through the getInstance() method. It can be easily called from any part of the code. Owing to this, we can get information about the current http query, as well as many other valuable parameters stored in it. But what should we do, if we want to replace Zend_Controller_Front with an implementation of the class of our own? This is utterly impossible because the remaining Zend_Controller library classes use this singleton and no clean way exists to change this. They will always use this class. We cannot edit all the other package classes because we will need to do this every time a new version of Zend Framework 1* is released.
Beside singletons, bad classes are all those that provide static methods having an important implementation, such as Zend_Controller_Action_HelperBroker – this class is statically called from many places and we cannot replace it with a class of our own.
Some limitations of Zend_Db
One of my favorite Zend components is Zend_Db.
Zend_Db is a well-designed database abstraction layer (DBAL) whose purpose is to put some object-oriented clothing on SQL queries. Design patterns such as Table Data Gateway and Row Data Gateway by Patterns of Enterprise Application Architecture have been utilized within the component’s structure. Using Zend_Db is a real pleasure. For a medium-complexity project, Zend_Db is capable of ensuring functionality without having to write a single SQL query.
So, what is wrong with Zend_Db?
It isn’t at all easy to criticize such a powerful tool but I have bumped up against some small limitations of the components.
The Zend_Db_Adapter class provides the 4 standard CRUD methods insert(), update(), delete() and select(), whose help lets you handle the respective SQL commands, but what limits the functionality of this class is that you cannot easily extend the functionality of any of these methods.
Take, for instance, insert(). This method generates an INSERT INTO … VALUES … query, but if I want to add the IGNORE keyword (to suppress errors triggered by repeated unique-key rows), I would hit a stone wall because no such setting exists in Zend_Db. The bad thing here is that there are no INSERT IGNORE queries, and I cannot easily alter Zend_Db to supply this functionality.
The situation with INSERT .. ON DUPLICATE KEY UPDATE is no different.
A new beginning for Zend Framework
One of the main goals of ZF’s first version was to standardize the use of PHP by promoting the new features of version 5. Many years have rolled after the framework’s first release and PHP has changed as well. Many of the features, intended for the long-awaited version 6 were launched in advance in the phenomenal version 5.3.
Indeed, the language has risen to a much higher level, resembling its big brother, Java. We were introduced to namespaces, callback functions and other interesting capabilities that emerged in the next version, PHP 5.4.
As time moved on, the community felt the need of a sample and stable implementation of all these features and a next major version of ZF was indispensable. Ideas about the future of the new framework were debated at large but it seemed like all of the energy was focused on Dependency Injection.
This is not so much a topic of instruction in the foundations of Zend Framework 2 but rather a propaganda. Which explains why you won’t see any specific examples of utilization and so on.
Yes, Zend Framework 2 was supposed to be Dependency Injection-based. But why? What could such a distant and fuzzy concept give us?
Actually, integrating DI in the PHP community was a serious step forward.
The most important benefit of the new ZF 2 architecture is that by utilizing Dependency Injection we can replace any library class with an implementation of our own. The use of interfaces is being promoted and there’s not a single word on singletons.
Replacing classes is done by means of special settings in the so called DI Configuration. I won’t give any specific examples because the aim of this article is to provide a short summary of the capabilities of Zend Framework 2.
Service Locator implementation
The combination of Dependency Injection and Service Locator is like making love to a very beautiful and delicate woman. Let’s assume Dependency Injection is the powerful but rough passion – then Service Locator adds delicacy and beauty.
When there are many dependencies in our system and they are all injected by means of a DI container, then there are many cases when some objects will have been injected without the need to, which will in turn adversely impact efficiency.
Service Locators solve this problem by supplying instances only when needed. Although this is a completely different pattern, it can be utilized in consonance with DI (which is common practice). The result is injecting not concrete instances but the Service Locator itself, through which access to the necessary services/installations is made.
Even though DI stands at the heart of Zend Framework 2, developers have no direct dealings with the container’s DI configuration. The DI layer itself lies hidden beneath a library known as Zend\ServiceManager, which is in fact a powerful implementation of the Service Locator. It is equipped with a configuration of its own, which in turn communicates with Zend\DI.
A new module system
YES! This is the thing we have truly needed! But what exactly does this new module system give us?
Portability is something that every programmer is striving to achieve. The purpose of the new module system is to concentrate the distribution of logic into modules so that the transfer and adaptation of the logic to other applications is facilitated.
In contrast with Zend Framework 1, the ZF 2 modules do not necessarily have to be MVC. You can write a module that supplies a library ensuring logic for other modules. We can, for example, have a PayPal module containing PayPal payment classes, but not the respective controllers, view scripts and models.
The brightest practical example of the power of the new module system is the newly created module dissemination community – http://modules.zendframework.com. Anyone can publish and use modules on this website. This will make the development of ZF 2 projects even faster and easier.
In Zend Framework 1, we were used to writing the platform configuration in .ini files. This ensured good readability but it some cases proved to be a thorn in the side of those looking for high efficiency. Besides, no default module configuration was being loaded.
In ZF 2, an associative array serves as the default configuration.
In addition to a global configuration, each module can provide its own configuration. When the system is started, the settings of all available modules are merged with the global configuration and loaded into the module-manager.
A hundred pages wouldn’t possibly suffice if I were to cover (even briefly) all of the ZF 2 innovations, but I have outlined the most important and noteworthy capabilities of the new platform. However, despite all the positive reviews of ZF 2, I do not think it is perfect. It is still at an early stage and I haven’t run into any troublesome characteristics but I am sure that some do exist.
It will give me great pleasure to witness the growth and development of the framework but if I could give some advice to the ZF developers, it would be to not rush Zend Framework 2.
Zend Framework isn’t the best framework – it simply is in the “Top 1” chart.