我是否应该使用psr-7进行拉拉请求/回复？

Question

我一直在使用slim 3，最终使我的头转到psr-7上。现在和laravel 我发现开箱即用，不支持psr-7。一起工作。

现在..。是否有很强的理由遵循psr-7或laravel的要求风格？

例如，个人偏好，并不是一个很强的理由。

我只是不想用laravel请求类来编写整个应用程序，也就是说，Illuminate\Http\Request只是想在一年内发现我真的应该遵循psr-7标准。

Answer 1

简短回答：No

较长的答覆：

考虑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的问题上被过多地纠缠在一起。只要做你的研究，并确保你选择的工具集最适合你的需要。