私はスリム3を使用していて、ついにpsr-7の周りに頭を浮かべました。今すぐlaravel i see that out of the box, psr-7 is not supportedで作業しています。laravelリクエスト/応答にpsr-7を使用する必要がありますか？
今、psr-7またはlaravelリクエストスタイルに従うことが必要な理由はありますか？
例えば、個人的な好みは、強い理由ではありません。
laravelリクエストクラスのアプリケーション全体をコード化したくないのですが、これはIlluminate\Http\Requestで、私が本当にpsr-7標準に従っていたはずの年を見つけてください。
短い答え：ません
ロング回答：
それはあなたのあらゆる面が選ばれたことをあなたに意味どれだけ（PHP標準勧告）PSRの目的を考えると、フレームワークはこれらの基準に従います。
要求/応答システムが組み込まれているSymfony Componentは、PSR-7に対応していないため、Laravelには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に準拠しているかどうかにあまり気を取らないでください。あなたのリサーチを行い、あなたのニーズに最も適したツールセットを選択してください。
素敵な答え。 – ceejayoz
今すぐ個人的な好みに戻る：あなたが最初からlaravelで新しいプロジェクトを開始するときは、あなたは個人的に何を使いますか？ – Toskan
私がLaravelを特定のプロジェクトに使用することに決めたのならば、私は通常、それが箱から出るものに固執するだけです。個人的には自分でPSR-7が好きですが、Laravelで行っているほとんどのプロジェクトでは、その種のコーディング標準は必要ありません。 – maiorano84
「私はちょうどあなたの個人的な好みのように聞こえたくありません。私はLaravelが最終的な移行を非常に簡単で滑らかにすることを期待します。 – ceejayoz
私は個人的な好みの「一年でコードを書き換えたくない」という理由はどうですか？ – Toskan
リファクタリングが好きな人もいます。 :-p – ceejayoz