我一直在使用 slim 3,最后终于了解了 psr-7。现在使用 laravel我看到开箱即用,不支持 psr-7。
现在......是否有充分的理由遵循 psr-7 或 laravel 请求样式?
以个人喜好为例,并不是一个强烈的理由。
我只是不想用 laravel 请求类编写整个应用程序,那Illuminate\Http\Request
只是想在一年后发现我真的应该遵循 psr-7 标准。
我一直在使用 slim 3,最后终于了解了 psr-7。现在使用 laravel我看到开箱即用,不支持 psr-7。
现在......是否有充分的理由遵循 psr-7 或 laravel 请求样式?
以个人喜好为例,并不是一个强烈的理由。
我只是不想用 laravel 请求类编写整个应用程序,那Illuminate\Http\Request
只是想在一年后发现我真的应该遵循 psr-7 标准。
简短的回答: 没有
长答案:
考虑 PSR(PHP 标准推荐)的目的,以及您选择的框架的每个方面都遵循这些标准对您意味着什么。
Laravel 没有开箱即用地支持 PSR-7,因为构建其请求/响应系统的Symfony 组件也不符合 PSR-7。事实上,这个组件通常是许多框架的核心,并且是在 PSR 的想法流行之前编写的。
为了让 Laravel - 或任何其他依赖此组件的框架 - 符合 PSR-7,它必须将其对 Symfony HTTP Foundation 组件的依赖更改为其他东西,或者甚至可能推出自己的实现。
请记住,所有 PSR 建议都只是:建议。
它们都不是必需的。
他们的唯一目的是帮助将 PHP 的编写统一为更可预测的格式,以便所有至少熟悉这些标准的 PHP 开发人员能够遵循并更轻松地理解每个符合要求的代码库。
没有令人信服的理由仅仅为了它而重构任何具有合理复杂性的代码库或框架以符合 PSR
正如您自己所说,个人偏好并不是彻底检查代码库的充分理由。
至于您的用例,您需要问问自己,与不兼容的框架相比,符合 PSR-7 的框架将为您实现什么。问题不在于可维护性,因为与不兼容的代码相比,符合 PSR 的代码的可维护性不高或不低。
如果您正在编写一个需要完全控制请求/响应生命周期的 API,那么最好使用像 Slim 这样的符合 PSR-7 的框架。如果您正在编写一个通用应用程序,其中您需要关心的唯一请求和响应是少数 AJAX 和 JSON 路由,那么您可能对 Laravel 或 Lumen 没问题。
不要过分关注给定的框架是否符合FIG。只需进行研究,并确保您选择的工具集最适合您的需求。