PHP Best Practices: Creating a Blueprint for PHP Applications

The Meaning of Life

What is the one true path to creating a successful PHP application? Does it exist? Does everyone know what it is? What dangers should I avoid? What works, what doesn’t? Is there a guide that will lead me down this path?

You may find the answer to these questions if you scour the net, know what you are looking for, and know who is right and who is wrong, or proven and unproven if you want to look at it another way. You may also find a web of entanglement mixing old and new information with many different versions of PHP and related products. You may also come up empty handed with no clear picture to be your guide.

We can do better. We can develop a solid mental picture of what ingredients make a safe, scalable, performant, and realistic PHP application. We can write the cookbook for PHP web applications covering the topic from corner to corner providing:

1. A sketch of typical web application architecture.
2. A roughed-in application to act as a application kernel.
3. A reference application based on the sketch and kernel application proving the goals are met.

Blueprints

Over a series of many articles, the Developer Zone will flesh out this “Blueprint for PHP Applications” and see what we can do with modern PHP, the Zend Framework, and other resources available to PHP developers. Early in the series, we will bring forward topics covering architectural areas of web applications to discuss with the community who can provide thoughts about what they feel is important for each, lessons learned, and best practices found. Later articles will bring the three deliverables into focus: the sketch as the mental picture of what an application looks like, a base application that can be used as a running sample or starting point for custom creations, and a reference application showing the full scope of the blueprint in action.

The blueprint is not meant to become a platform, an overly large application server, a framework replacement, a huge pile of XML configuration files, a CMS, or a plugin model for application building. It will be a delicate balancing act to provide guidance, best practices and a bit of proving code, while avoiding becoming a framework in itself.

What is a PHP Application?

This wouldn’t be a grandiose article without asking a really big question up front, well, besides the “meaning of life” question I opened with. Regardless, it needs asking as it sets the tone for future work; so here goes: What is a PHP Application? What is in scope of our blueprint building effort?

This sounds like a brainstorming question if I’ve ever heard one, so out comes the mind mapping tool. Here are the results of the initial brainstorming:

Given the rules of brainstorming, “every idea should be recorded and you can sort the mess out later,” I decided to not dwell too long on what perfectly fits or doesn’t, and instead get it into your hands for comment. You could argue that some items should or should not appear on the diagram, that some need further explanation, that you have additions to make and statements to be heard. I fully expect that you will do so and look forward to your comments (posted below).

Getting Started

In the meantime, it is clear that some core items from the brainstorming will survive regardless of any amounts of discussion. These will become the first few parts of the series, to explore each, draw out ideas and start developing the best practices for the architecture and application kernel. We can also begin the accompanying architecture diagrams for both the global view of the entire application, and the more narrow diagrams of the participating components. So let’s get started…

Coming up, Blueprint for PHP Applications: Cornerstone covering the principles of the blueprints, philosophical goals, concrete goals, and the breakdown of the major focus areas.

Digg This!