In my attempt to turn you nerds into uber-nerds, I’ve been lucky enough to get the young and talented Jon Lebensold (my right hand nerd) to bang out a few articles (and soon videos) on some of the emerging PHP technologies and working practices that take PHP into the enterprise arena.
Enterprise arena = sophisticated scalable and adaptable code.
About this article:
The following article introduces you to ‘web application frameworks’. If you don’t know what this is, read on and you soon will. But for those of you that are impatient … in a nutshell:
A web application framework is a set of code libraries (in our case, that would be libraries written in PHP) that handles/does many of the things that we typically need to do when building database driven websites.
For more details, you need to read the article.
The Zend Framework: Writing Object-Oriented PHP with Ease.
By: Jon Lebensold
This article aims to introduce the concept of developing a PHP application with a set of libraries that facilitate development by abstracting ones self from writing generic libraries.
We know that classes are composed of behaviours (methods) and data (properties), however their value only becomes apparent when we develop applications in layers, with different components answering different questions.
What Does a Layered Development Approach Look Like?
I find that layered development leads people to asking simple questions about the objects (or classes) that they’re writing. The following diagram illustrates how different layers in an application can answer very different questions. When you deal with applications in a flat manner, there’s a tendency of answering these questions simultaneously, leading to a coupling of concerns.
Separation of Concerns
A layered development approach is an extension of a Seperation of Concerns, essentially encapsulating larger problems into isolated objects that answer simpler questions autonomously.
In the early days of SmallTalk, a design pattern known as MVC (Model-View-Controller) emerged. This is but one example of a layered development process. Folks coming from an ASP.NET or Java background will be familiar with the work of Martin Fowler and the Gang of Four (among others), who’ve codified a lot of the repetitive work we do into patterns.
An example of a high-level design pattern would be the Active Record pattern., Active Record was brought into nerd pop culture through the Ruby on Rails team and Pragmatic Programmers. Martin Fowler describes Active Record as “An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.”
Essentially, you end up creating objects in your programming language of choice that closely resemble your database tables and rows. The advantage here is you spend less time switching from PHP to SQL and spend more time writing descriptive code. For example, writing:
$employee = Employee::FindByName(“sam”)
… instead of:
$employee = my_db_select_statement(“SELECT * FROM employees WHERE first_name = ‘sam’”);
Why Bother Using a Framework or a Design Pattern? I can write this xyz piece myself!
You walk into an architect’s office. You tell him that you want a house with so many rooms. He then asks you how high you want the door knobs on every door. And how wide you want the baseboards, and kind of cocking you want to apply to keep the building insulated. These questions go on and on and finally end up with a house that’s functionally correct but lacking in experience.
Web Applications are Houses… With a Lot of Renovations
The architect spent all this time asking you about things that could have been standardized, versus spending the time to make sure that the colour of the building, the texture of the tiles and the experiential qualities of your new home were exactly as you envisioned them. At the end of the day, the client spent most of his money and most of your time re-inventing the wheel.
You ended up spending more time writing the foundation code (caching engine / persistence layer / session management object / mail handler / XML transaction handler / logging framework / etc…) than the code your client will actually see and interact with.
The job of a software architect is even more fluid than that of a building architect since a web application is never really done, its a process of releasing a newer and better version out the door. If you’ve done a good job on your first deliverable, version 2.0 isn’t a possibility, its a question of when.
To enable yourself to spend more time flushing out project requirements, an application framework is a good place to start. There are many to choose from: PHPCake and Zend seem to be the dominant ones in PHP and the Rails framework (written in Ruby) has been gaining a lot of traction as of late as well.
What is the Zend Framework?
The Zend Framework is a set of PHP libraries that coexist nicely, allowing developers to build consistent, secure and extendable web applications without spending time writing what most would deem the repetitive and boring.
The Zend Framework is composed of a whole collection of components which Bill Karwin, product engineering manager for Zend, divides into six general groupings. I’ve provided a short list of the components he highlighted in his webinar in June 2007:
- Zend_Translate… (omitted for brevity)
- Zend_Feed… (omitted for brevity)
Mail, Formats, Search
The Zend Framework is appealing to me for a couple of reasons:
* IBM is backing this initiative, with money and programmer resources.
Big Blue has been around longer than I would venture to guess that they’ll be around at least as long as my web applications are still in use. With millions invested and the kind of white papers they’re releasing, I can imagine that the Zend Framework will mature into a nice product.
* Zend is behind the Zend Framework.
Let’s not forget who Zend is: they’re “The PHP Company”, with the creator(s) <
* Zend doesn’t enforce one particular pattern or practice.
The Zend Framework differs from PHPCake and Rails in that each library can function independently of each other. Most tutorials out there describe a scenario where Zend_Db is combined with Zend_Controller and Zend_View. These three modules form the base of an MVC framework, however, ZEND is not limited to this paradigm. You could implement just Zend_View for templating or create a cron job running off of Zend_Db for managing data integrity among data sources. This kind of flexibility leaves the ball in your court.
* One day Zend Studio will grow up.
Without attempting to belittle the efforts of the Zend group, their IDE still seems to be undergoing growing pains. My experience from running the trial 6 months ago was that it was unintuitive had a very limited debugger. Personally, I prefer using PDT and I’m looking forward to their Zend Studio Eclipse extensions. Regardless, I don’t see as much of a push from any other framework group.
* Java Integration Considerations
Without getting into a flame war over strong type / weak typed languages, embedding JAR’s into PHP applications is going to be an inevitability in the coming years. With Big Blue behind the Zend initiative and the push for PHP to answer business needs, I can see the gap between Java and PHP beginning to close with Java integration and Zend providing wrappers that will facilitate integrating Java business objects.
I’ll be diving into some proper coding examples in my next article. Initially dealing with some Zend libraries that compliment any kind of development (even if its not MVC-specific).
This entry was posted on Wednesday, November 21st, 2007 at 11:26 am and is filed under Advanced PHP, Object Oriented PHP, Zend-Framework. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.