Zend Framework has been right up there as one of the most preferred PHP frameworks for a long time. With massive tech community support that keeps on adding interesting and innovative features to the ZF library, it has emerged as the de-facto PHP Framework for developers globally.

What is DI in ZF2

One such feature set that was implemented into Zend Framework 2 and above, is the Dependency Injection feature, which addresses the problem of managing object dependencies. It denotes a better programming practice of writing more flexible code, that helps edit the dependent class without having to alter class’ code.

In Zend Framework, Dependency Injection facilitates decoupling of the object from the class so that it no longer is applicable to just that class but is adaptable enough to be re-used in other parts of the program as well. DI will reshuffle the object’s responsibilities from within the class to a new external entity. This external entity is nothing but the Controller of the relevant framework.

In Zend, the ‘Zend_Controller_Action’ instance will act as the Controller. However interestingly enough, this instance too is a dependent object, thus largely negating DI principles. Developers  could do well to take it a level above by invoking bootstraps. In ZF2, ‘Zend_Application’ is a bootstrapping approach where developers use a method/class to create an object and call it as needed by a controller.

Why DI?

1. Clean coding – Dependency Injection goes a long way to allow developers create clean and compact codes and not define new objects every time simply because they were present inside a class.
2. Re-usability of codes – The best and perhaps the most critical advantage of DI in ZF2 is that the codes no longer have to be relevant to just the class within which it was defined. Through Dependency Injection using a Controller/bootstrapping option, it becomes fairly easy to re-use the method/object elsewhere in the framework rather than revising it in the parent class or creating a new object outside the class.
3. Development time – Since developers can work around redundancies by re-using the code, a significant amount of programming and testing time is shaved off thus leading to lesser overall development time.