Now that the host for underwater.com.au has upgraded to PHP5 I'm working on migrating it to use the Zend Framework. I thought it may be interesting to run through a few of the reasons I've chosen to do so especially while the framework is in such an early stage of development.
"Underware"
The engine, code-named "Underware", that underwater.com.au currently runs on is built almost entirely (excluding a few additional class files) from my own code. Developed, via several projects, over the course of about five years from a modified version of the PHP e-Commerce application Freetrade and the FreeEnergy structure (Actually, it's interesting to look back over that FreeEnergy article to see how it's almost a Model-View-Controller structure), Underware is now more object-oriented, more MVC'ed and more woven with design patterns than its early incarnations, however it still has loose threads.
Why grow your own?
Considering the amount of freely-available, open-source, PHP code it seems idiotic to be doing it all yourself. Sadly, the number of applications available is no indication of their quality, nor whether they will play nicely together, a point taken up by Clay Loveless in his Stop Writing Loner Applications post.
At every stage of Underware's development I looked at pre-existing solutions, hoping to find one that wouldn't force me to duplicate components I already had, such as user management. It wasn't necessarily that I had better code, more that what I did have was only what I needed. Besides, I knew as I worked on it the code quality would also improve. Inevitably, after spending many unbillable hours pouring through different solutions I'd look at the clock and think "I could have spent those hours moving forward and coding a solution"!
Pros of doing it all yourself
- You only build, debug and support what you need.
- You know all the code.
- You learn a lot.
Cons of doing it all yourself
- You have to build and support every bit of code and unless you build it it's not just going to appear from somewhere.
- You have to document it all.
- You have to spend time researching solutions to every issue, including system level ones that are not directly providing solutions for your clients.
Thankfully the increasing amount of frameworks available (i.e. rather than finished applications) combined with the growing object-oriented'ness of PHP mean it's less of an either or situation.
So why Zend Framework?
Honestly, I think because it feels right and I say that not to be facetious, but partly because I see so many lengthy arguments for and against such and such framework as if one or the other holds the golden key. Part of the reason I went back to my roots was to show the influences on my way of structuring web applications and if you're interested enough to look into them you may see some similarities. For me the Zend Framework not only fits the way I'm currently working but moves it forward, tying up some of the aforementioned loose threads for example.
More pragmatically there are factors like the fact that my clients can worry less about being so totally dependant on me for every facet of their applications; I can benefit from all the external input to the framework itself; I can focus on solving client needs more and system level needs less and not to be ignored is the Zend part of the framework which for me puts at least some stamp of longevity and consistency on the code base.
Some further Underware influences
Philip Greenspun's Software Engineering for Internet Applications, in particular the section on content management.
Design patterns picked up from various sources, but really understood in Head First Design Patterns and phpPatterns. The Head First Java is also a good read, particularly if like me you're really only after a better understanding of OOP rather than wanting to specifically program Java applications.
Marcus Baker's articles on unit testing. I plan to read more about PHPUnit too but Marcus' writing was really a good intro to a practice I must practice more of!