将非框架 PHP 项目移植到 Laravel 4.x

Posted 2023-02-22

【中文标题】将非框架 PHP 项目移植到 Laravel 4.x

【英文标题】：Porting a non-framework PHP project to Laravel 4.x

【发布时间】：2014-06-21 10:57:50

【问题描述】：

我有一个大型 php 项目，其中我没有使用任何框架（也没有使用 MVC 模式），我想逐渐将它移植到 Laravel 上，并且（几乎）没有停机时间。 我正在寻找使已移植到 Laravel 的代码片段的迁移变得透明的方法，同时保留功能性较旧的纯 PHP 代码。 例如，Laravel 使用类和方法（例如 Input::get()）“覆盖”超全局变量（$_GET、$_POST 等）。我的普通 PHP 项目当然直接使用了超全局变量。如何在 Laravel 下克服这些“不兼容性”，而不必立即重写我所有的 PHP 代码？否则，如果您认为这项任务太难了，是否有任何 PHP 框架，由于其内部结构，会让这项任务更容易吗？

更新： 在 laravel 中仍然可以使用超全局变量。我得到一个鬼鬼祟祟的错误：Laravel 内部将 error_reporting 设置为 E_ALL 并显示自定义错误堆栈跟踪页面，即使对于 PHP E_NOTICE，但 没有明确指定错误级别（这是一个 NOTICE 错误），甚至如果这是 PHP 错误报告消息引擎默认完成的。让我说，对于 Laravel 核心开发人员，我认为这种“部分沉默”的行为通常会误导任何试图移植其代码的 PHP 开发人员到他们的框架。

【问题讨论】：

你仍然可以在 Laravel 应用程序中使用 PHP 超全局变量（$_GET、$_POST 等）。

谢谢，您的评论让我找到了解决方案。我相应地更新了我的问题。

您的项目结构如何？您是否使用任何表示层与业务逻辑层的分离？？？

@DotMat - Laravel 故意设置错误级别，因为您通过 app.php 中的配置文件控制它。打开/关闭调试并根据需要使用。您还可以根据需要记录不同的错误

@theshiftexchange - 是的，但重点是：为什么不在默认堆栈跟踪页面中报告错误级别？废话。

【参考方案1】：

TL;DR

不要这样做。

常见的误解

如果你有一个现有的项目，那么将它移植到一个框架上不会给你带来任何好处。框架不是某种魔法酱，它奇迹般地使代码更好或使网站运行得更快。

相反，框架是工具，它（据说）通过已经完成“常见任务”来帮助您在更短的时间内编写项目。此外，作为副作用，在项目中停止使用框架非常困难（例如，如果它停止使用），因为您的所有代码现在都与框架紧密结合。

这就是您目前遇到这些问题的原因：

如何在 Laravel 下克服这些“不兼容性”，而不必立即重写所有 PHP 代码？

你不能。完全按照 Laravel 框架的要求重写它，否则它将无法工作。

(..) 是否有任何 PHP 框架，由于其内部结构，可以使这项任务更容易？

不，没有。所有流行的框架都希望您重写代码，以便将其绑定到框架。

更好的方法

但是您已经有了一个可以工作的应用程序。如果您专注于改进现有代码库，您将获得更好的结果：

确保您关注SOLID principles 将您的业务逻辑与您的表示和数据库抽象分开 开始为您的代码中非常阴暗部分添加单元测试 重构，重构，重构

_{PS：列出的材料here可能会有所帮助}

【讨论】：

开发人员不应该已经在做所有这些了。这些是常见的编码实践，但很好地提及不有助于回答作者的问题。

@sidneydobber 很多人没有做他们应该做的事。这些天来，我倾向于假设不遵守最佳实践，但也许这只是让我厌倦了。

@Dan Lugg 你是对的！只是有更多的开发人员涌现出来，优秀的开发人员需要向他们展示干净、清晰的代码和大量的积极强化！ ;)

感谢您的意见（以及您的最终链接），这让我对这个问题有了新的认识。现在我还没有决定将项目逐步移植到 MVC 框架的想法。如果不能太难达到向后兼容性，现代框架强加的 MVC 结构可能对保持最佳编码实践有很大帮助。对我来说，这就是重点：强迫自己写好代码，避免对自己的技能和资源过于自信，同时确保未来有适当的灵活性。这确实是一个大问题。