What PHP application design/design patterns do you use?

Question

Please share your favorite application design / design patterns for use in PHP with me. Some things I\'d like to know:

• How your folders are designed
• How y

Answer 1

I might get voted down for this, but if you really do want to write your own framework, I say go for it because you will learn a lot from the experience. The other frameworks mentioned here are great and tested and you wouldn't be making a bad decision using them, but it's your choice.

Before starting to write your framework, look at the other frameworks (at their syntax, directory structure, naming schema, design patterns, etc) and try to figure out why they did what they did and what, if anything, you would do differently. Try out a few tutorials and play with their code, make a few sample apps. If, after doing that, you don't like using them, then go ahead and start planning your framework, keeping what worked and improving what didn't.

If you do decide to roll your own, here are a few things I would recommend from my own experience:

• Make Security Your Top Priority - If you write a data access layer, use bound parameters. If you write a form class, guard against CSRF and XSS. Catch your exceptions and handle your errors. Make sure that your PHP environment is secure. Don't try coming up with your own encryption algorithm. If you don't concentrate on security, it's not worth writing your own framework.
• Comment Your Code - You will need comments to help you remember how your code works after a while. I usually find that docblock comments are more than enough. Beyond that, comment why you did something, not what you did. If you need to explain what, you may want to refactor.
• Single Responsibility Classes and Methods - Most of your classes and methods should do one thing and only one thing. Especially watch out for this with the database - Your pagination class shouldn't rely on your data access object, nor should almost any other (low-level) class.
• Unit Test - If each of your methods does only one thing, it should be far easier to test them and it will result in better code. Write the test first, then the code to pass the test. This will also give you greater freedom to refactor later on without breaking something.
• Abstract Similar Classes - If you have more than one class that does similar things, create a parent class that uses the similarities between the classes and extend it.
• Delegate and Modularize - If you're writing a validation system (and chances are you probably would), don't include each validator as a method in some super validation class. Separate them into individual classes and call them as needed. This can be applied in many areas: filters, languages, algorithms, validators, and so on.
• Protect and Privatize - In most cases, it's better to use getter and setter methods rather than allowing direct access to class variables.
• Consistent API - If you have a render() method and a draw() method that do the same things in different classes, pick one and go with it across all classes. Keep the order of the parameters the same for methods that use the same parameters. A consistent API is an easier API.
• Remember Autoloading - The class names can get a little clunky and long, but the way Zend names the classes and organizes the directories makes autoloading a lot easier. Update: As of PHP 5.3, you should begin using namespaces.
• Never echo or print anything - Give it as a return value and let the user decide if it should be echoed. A lot of times you'll use the return value as a parameter for another method.
• Don't Try to Solve the World's Problems - Solve your own first. If you don't need a feature right now, like a class for localizing numbers or dates or currency, don't write it. Wait until you need it.
• Don't Preoptimize - Build a few simple applications with your framework before fine tuning it. Otherwise, you can spend a lot of time on nothing productive.
• Use Source Control - If you spend countless hours creating a masterpiece, don't risk it getting lost.

Answer 2

I almost feel like a broken record, but I would recommend that you take a look at some of the common frameworks for two reasons:

1. Even if you choose not to use one, some of them are very well written and very well designed. I particularly like Zend Framework but I'll come back to that in a second.
2. Ask yourself why you're reinventing the wheel. Do you really feel that you understand the same design problems everyone else faces so much better than the community behind (insert framework of choice here) to justify writing something from scratch? Speaking as one who originally looked at several frameworks and decided that they were too big, presented too much of a learning curve or too much overhead and so developed my own, I can tell you that writing your own from scratch is a big pain if you can simply use an existing one that can be easily extended.

Speaking of using a framework that can be easily extended, I have had very positive experiences with Zend Framework. It's cohesive and yet loosely coupled structure makes it possible to quickly and easily extend any existing component and the entire framework is designed around the idea that you will need to write your own helper and plugin classes to add to its overall functionality.

I've found Zend Framework to be so completely flexible that I am running a single website as part Zend Framework MVC and part my old crappy framework and even older crappier code that I haven't gotten to rewrite yet. In fact, because during our rewrite we found one page that ran unacceptably slow using the old framework, I've switched the single page to run under the Zend Framework architecture.

To answer some of your questions, I would recommend that you look into Patterns of Enterprise Application Architecture by Martin Fowler. He provides a lot of valuable insights into how to solve a number of these common problems like how to create a database interaction layer in your application. Fowler also covers topics like MVC and Front Page Controller.

Answer 3

Using Zend Framework and Doctrine, my folder structure usually looks like this:

root
  app
    config         (db config, routing config, misc config)
    doctrine       (fixtures, migrations, generated stuff, etc)
    lib
    logs
    models         (doctrine models)
    modules        (zend mvc modules)
    bootstrap.php
  docs             (db diagrams, specs, coding standards, various docs)
  pub              (web root)
  tests
  tools            (console tools, i.e. doctrine-cli)
  vendor           (zend and doctrine libraries, preferably as svn-externals)