Tos*_*kan 5 laravel laravel-5 psr-7
我一直在使用超薄3,最后我的头围绕psr-7.现在使用laravel 我看到开箱即用,不支持 psr -7.
现在......是否有充分理由遵循psr-7或laravel请求样式？
例如,个人偏好不是一个强有力的理由.
我只是不想用laravel请求类对整个应用程序进行编码,这Illuminate\Http\Request只是为了找出我真正应该遵循psr-7标准的一年.
简答: 不
答案很长:
考虑PSR(PHP标准建议书)的目的以及对您所选择的框架的每个方面都遵循这些标准的意义.
Laravel没有开箱即用的PSR-7,因为构建其请求/响应系统的Symfony组件也不符合PSR-7.实际上,这个组件经常出现在MANY框架的核心,并且是在PSR的概念出现之前编写的.
为了使Laravel(或依赖于此组件的任何其他框架)符合PSR-7标准,它必须将其对Symfony HTTP Foundation组件的依赖性更改为其他内容,或者甚至可能将其自己的实现转换为其他内容.
请记住,所有PSR建议只是:建议.
它们都不是必需的.
它们的唯一目的是帮助将PHP的编写统一为更可预测的格式,以便所有至少熟悉这些标准的PHP开发人员能够遵循并更容易理解符合的每个代码库.
没有令人信服的理由重构任何合理复杂的代码库或框架,只是为了它的PSR兼容
正如您自己所说,个人偏好不足以彻底改变代码库.
至于你的用例,你需要问自己一个PSR-7兼容的框架将通过一个不合规的框架为你实现什么.问题不在于可维护性,因为符合PSR的代码与不符合规范的代码不同 - 或者不能 - 维护.
如果您正在编写一个API,您需要完全控制请求/响应生命周期,那么可能最好使用像Slim这样的PSR-7兼容框架.如果您正在编写一个通用应用程序,其中您将关注的唯一请求和响应是少数AJAX和JSON路由,那么您可能对Laravel或Lumen很好.
不管是否给定的框架是否符合图,都不要过多地陷入困境.只需进行研究,确保您选择的工具集最适合您的需求.
| 归档时间： |
|
| 查看次数： |
1473 次 |
| 最近记录： |