PHP框架糟透了系列：如何避免让你的应用变成框架的样子

AWS 安全直播！

引言

下面这张图是我在题为“PHP框架的弊端”的演讲中使用的，当时我试图解释过度依赖框架会导致什么问题。这张图是一个公寓的平面图，房间的角落没有公度角。所以你可以想象，当你搬进这样的公寓时，你必须根据房间的角落形状定制家具。否则，你将无法用市面上常见的标准家具来布置你的新家。 我们再举个例子。假设你搬到了一个新的城市，选择不多，你选中了这套空荡荡的公寓，然后开始慢慢添置家具。几年后，你决定搬到另一套公寓。但是你之前拥有的家具该怎么办呢？搬到新公寓后，你不得不扔掉它们，重新购买新的家具，因为新公寓的房间布局完全不同，这次都是标准布局，所以你之前“定制”的家具不再适用。

框架无法改变。

定制家具完美地诠释了开发者如何围绕框架构建应用程序，结果却发现无法在其他环境（其他框架或库）中继续使用。框架会引导你将应用程序组织成特定的文件夹结构，这本身并无不妥，但一旦框架发生变化，就可能成为一大障碍。你或许不必更换整个框架，因为这种情况并不常见，但有时仅仅是同一个框架，不同的主版本就足以让你的应用程序彻底失效。我想大家都记得从 Zend 1 迁移到 Zend 2 的过程。我从未听说过有哪家公司成功完成了这项任务。

结论

由此我们可以得出结论：每当公司或开发者需要更换框架时，他们几乎都不得不重写整个应用程序。对于已经盈利的大型系统而言，大规模重构或系统重写尤其棘手，因为你不可能在用新框架重写时就将其搁置一边。我在职业生涯中无数次目睹这种情况：由于框架绑定，公司无法升级。他们过去称之为“遗留问题”，因为这是“随着时间推移自然而然发生的”，你对此完全无能为力。我很少看到有公司强制执行领域驱动设计（DDD），并强制将业务与工具分离，因为框架本质上只是工具。

我的发现

我个人坚信（而且我已经证明了这一点），将业务逻辑与框架分离能为公司带来长期的经济效益。无论框架版本如何更新，或者我们想将组件与其他框架或库集成，只要我们将业务逻辑与框架分离，就能轻松实现。我最近展示了一个项目，该项目有望与 PHP 的生命周期一样长（并且不会发生剧烈的变化）。该项目拥有 100% 的单元测试覆盖率和行为测试，以确保所有功能始终正常运行。此外，该项目与框架高度独立且抽象，因此我们可以在一周内将其移植到另一个框架中。我的公司认为该项目将持续运行五年以上，这意味着我们无需进行任何“重大重构”或“大规模重写”。如果这还不足以证明经济效益，我想不出还有什么更明显的例子了。