- Zend Framework. Development evolution in PHP.
If you are interested in Zend Framework development characteristics and evolution, this post is the right thing for you to find information.
PHP is designed specifically for server-side programming. PHP is suitable for majority of operating systems including Unix and Windows, and it is an excellent server-side programming language for professional web development.
PHP has changed incredibly during the last six years. With the release of PHP 5, we’ve started focusing on solid programming practices. With a revised and reworked object models, we have now a solid basis on which we can build our re-usable objects for customized web projects. When these changes happened PHP frameworks appeared and became popular. While some of them were invented for PHP 4, the idea blossomed out in PHP 5, and a number of frameworks were created.
These frameworks aimed to provide their users with the best practices, and to give repeatable, reusable structures for the applications they built.
Zend Framework is one of the frameworks among them. Zend Framework’s mission, according to Zend web site is:
“Extending the art and spirit of PHP, Zend Framework is based on simplicity, object-oriented
best practices, corporate-friendly licensing, and a rigorously tested agile codebase. Zend Framework is focused on building more secure, reliable, and modern Web 2.0 applications and Web services, and consuming widely available APIs”.
How we are using Zend Framework?
Design of Zend Framework is presented by a rich collection of different classes. The main plus of Zend Framework is that we can use Zend MVC components to create a fully-functional ZF project, and at the same time we can just load some separate components we need. As ZF is absolutely decoupled, we can take advantage of using any components as individual libraries, instead of taking the whole framework.
There is a widespread term ”a glue framework”. ZF is a perfect glue framework. Its disconnected structure turns it very easy to use as “glue” to combine already made components or applications.
Zend Framework has plenty of elements. If we need a way to authenticate a user, we use Zend_Auth. If we need to control access to our resources, we look up Zend_Acl. If we need to create some forms, we have Zend_Form. For read an RSS feed we can use Zend_Feed for that.
The documentation Zend Framework’s is fundamental. It is presented by more than 500 pages in 6 languages. API documentation is accessible online in the public domain for viewing and for download the same as the reference guide.
Everybody can find a number of demos that teach how to use Zend framework and its different components.
Zend Framework. Integration with other libraries is not a problem.
Tutorials, such as Zend Framework Quickstart tutorial, are intended to show good ways to implement models. In the tutorial, one can get to know how an ORM approach to the models can be implemented, wherein you would create three files: an abstract pattern of your object – the actual Model; a Mapper, which contains maps data from the database; and a Database Table object, which is the data source for the mapper. The code may be also checked out in the Zend Framework Quickstart tutorial.
Zend Framework’s decoupled nature not only makes it very easy to integrate other libraries in which there is a need during work process, as in case a developer uses Smarty as a template, he can just create a wrapping class for Zend View Abstracts. It works also vice versa, as one can integrate ZF into other libraries without any problems as well. For instance, ZF elements can be integrated into Symfony 2 using Zend Cache and Zend Log components.
MVC and Zend Framework.
Zend Framework does not define the only certain way of implementing features in Zend application development. We can say that it offers instruments and suggests some patterns for custom projects. A programmer totally controls the way of implementation of applications or features. It is one of the reasons why Zend_Model component does not exist. In the MVC design, the M means “Model”. Development of the model in MVC depends mostly on the application itself.
There is no its own Model implementation in Zend Framework. That leads to some difficulties in ZF web development for some people. It is especially evident when they have begun working from a framework which does have a Model implementation (for example CakePHP, Symfony, or even Ruby on Rails).
At the same time, Zend Framework is an MVC framework as well because it actually shows some sort of Model implementation apart from allowing to use general ways to access the database (using Zend_Db).
The main difference of ZF is that it leaves the main part of model implementation up to the developer who can make decisions depending on the logic of the app and the needs of the business.
Zend Framework Philosophy emphasizes that model implementations should be unique for every project, it is impossible to make a pattern that could be suitable in any case, before getting the information about real final goals of the web application.
Not having a Model implementation means that a Zend developer is free to use any tools he has to implement it, or even just integrate existing implementations. Not having predefined choices, the developer is then free to create more complex implementations, rather than just simple representations of tables, which is how usual Model implementations are created.
Models must be built on the business logic. They should not be restrained by the database tables; on the contrary, they should define the connections of these tables. This lets you put most of your programming code in your Models during Zend development, therefore satisfying the “Thin Controllers, Fat Models” paradigm of MVC:
- Models are representatives of the Database, and they should obey the business logic
- Controllers act in connection with Models and take from them the information they need
- This information is then passed by a Controller to the View and is rendered
- Model directly interacts with a View in exceptional cases, but it may happen time to time if necessary
- Models can be built in connection with other Models and they aren’t self-contained. They have relationships that make them interlace with one another
- These relationships allow a Controller to get information faster and easier, since it doesn’t have to find with different Models – the Models can do that themselves
Now we can see that it is quite difficult to overrate models in any custom application, since they are responsible for any dynamic actions that applications performs.
