组织PHP类层次结构的最佳方法

Question

I've got a somewhat primitive framework I've been using for most of my projects, but a general design issue came to mind that I haven't been able to work out yet. For a given application, should I separate the application-specific class structure from the framework's structure, or is building on top of the framework not such a bad thing?

For example, say I had a framework with a base Controller class and extended it for a given part of my application. Which arrangement makes the most sense, and why?

Class Structure A:

• Intuitive, easy to find source files when debugging.
• File naming/directory structure mirrors class heirarchy.

- Framework_Control                 "Framework\Control.php"
   - Framework_Control_Index        "Framework\Control\Index.php"
   - Framework_Control_Home         "Framework\Control\Home.php"
   - Framework_Control_Contact      "Framework\Control\Contact.php"
   - Framework_Control_About        "Framework\Control\About.php"

Class Structure B:

• Keeps framework modular and easily to replace/update.
• Adds some complexity to directory structure, directory/file naming no longer follows class heirarchy all the time.

- Framework_Control                 "Framework\Control.php"
   - Application_Control_Index      "Application\Control\Index.php"
   - Application_Control_Home       "Application\Control\Home.php"
   - Application_Control_Contact    "Application\Control\Contact.php"
   - Application_Control_About      "Application\Control\About.php"

I know overall it's going to come down to personal preference, but I want to make sure I weigh out all the pros and cons before I decide which way to go. It really comes down to class naming and directory structure as the actual hierarchy would remain the same in either case.

Answer 1

I would suggest that you view your source code in two different categories, external dependencies or code that is used across multiple sites and not native to any single one and native dependencies or the code that is native to the particular site that you're working on.

It sounds like Framework/Control.php is part of a larger external dependency and should be managed as such, while the Application/Control files are all native the particular website.

Using this differentiation in our code structure has made it much easier to reuse our in-house framework between multiple sites very easily.

As a final thought, you might consider looking at what the major frameworks out there are doing such as Zend Framework, Symfony and others. Even though the entire framework might be more than you want the structure of the frameworks can provide a lot of insights into common, good practices that are being used by PHP developers everywhere.

Answer 2

What it really comes down to is what are you going to do when you update Framework\\Control.php in Application XYZ. Are you going to go back to Application ABC and make that same change? What if it's a critical bug?

For maintainability of all of your projects I'd go with your second option.