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

Question

我的大多数项目都使用了一个有点原始的框架，但是一般的设计问题让我想到我还没有完成任务。对于给定的应用程序，我应该将特定于应用程序的类结构与框架的结构分开，还是构建在框架之上并不是一件坏事？

例如，假设我有一个带有基本Controller类的框架，并为我的应用程序的给定部分扩展它。哪种安排最有意义，为什么？

班级结构A：

• 调试时直观，易于查找的源文件。
• 文件命名/目录结构镜像类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"

班级结构B：

• 保持框架模块化，轻松更换/更新。
• 为目录结构增加了一些复杂性，目录/文件命名不再一直跟在类heirarchy之后。

- 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"

我总体上知道这将归结为个人偏好，但我想确定在决定走哪条路之前，我要权衡所有的利弊。它实际上归结为类命名和目录结构，因为实际的层次结构在任何一种情况下都保持不变。

Answer 1

我建议您在两个不同的类别中查看源代码，外部依赖项或跨多个站点使用的代码，而不是任何单个站点和本机依赖项本机的代码，或者是您所特定站点的本机代码。重新开始工作。

听起来像Framework / Control.php是更大的外部依赖项的一部分，应该这样管理，而应用程序/控制文件都是特定网站本地的。

在我们的代码结构中使用这种差异化使得在多个站点之间轻松重用我们的内部框架变得更加容易。

最后一点，您可能会考虑查看Zend Framework，Symfony等其他主要框架。尽管整个框架可能比您想要的更多，但框架的结构可以为PHP开发人员在各地使用的常见，良好实践提供大量见解。

Answer 2

在应用程序XYZ中更新Framework \ Control.php时，您要做的是什么？你打算回到Application ABC并做同样的改变吗？如果这是一个关键的错误怎么办？

为了保证所有项目的可维护性，我会选择第二种方式。