PHP フレームワーク、傷つくかどうかに関係なく、傷つくことはできません

PHP フレームワーク、傷つくわけにはいかない、傷つくわけにはいかない

Rails がフレームワークのトレンドになってから、他の言語もそれに対応して、静的言語と動的言語の両方で Rails モデルを模倣したフレームワークが登場しました。 PHP 言語の主流は 5 つ以上あり、未知のフレームワークも含めると、少なくとも 20 種類以上のフレームワークがあると考えられます。 ！

PHP フレームワークへの道は、PHP がフレームワークを使用すべきかどうかから、Rails を模倣すべきかどうかまで、常に論争に満ちていますが、PHP フレームワークの爆発的な成長に匹敵するものではありません。いくつかのフレームワークと紹介のリストを次に示します。 「海外で最も人気のある PHP フレームワーク トップ 10 のランキング」という記事です。よりよく知られている PHP フレームワークには、CodeIgniter や CakePHP などの中小規模のフレームワークと、Zend や Symfony などの大規模なフレームワークが含まれます。 PHP にはなぜこれほど多くのフレームワークがあるのか​​疑問に思っています。
1. PHP 開発フレームワークは「簡単」すぎる
正直に言うと、PHP で Web フレームワークを開発する敷居は、PHP 自体がすでに他の言語よりもはるかに低いです。これをサポートするには、最初に 1 つのエントリの Index.php を作成し、次にモジュールとアクションのパラメーターを介して対応するコントローラー クラスとビュー コードを実行するだけで十分です。熟練したプログラマーなら 1 ～ 2 日かかります。単純すぎると思われる場合は、$_REQUEST、$_SESSION のカプセル化、データベース操作のカプセル化など、もう少しカプセル化してください。この時点で、まともな PHP の「MVC フレームワーク」は基本的に準備が整いました。より熟練したプログラマーであれば、1 週間で完了する可能性があります。
他の言語とは対照的に、Ruby を例にとると、Ruby の高い柔軟性と複雑な構文も相まって、REQUEST、パラメータ解析、その他の基本的な機能の処理だけでも 1 週間をはるかに超える作業負荷が必要になります。手頃な価格のフレームワークを開発するために必要なエネルギーは、通常をはるかに超えています。フレームワーク開発の敷居が低いことが、PHP フレームワークの普及に寄与する要因の 1 つです。

?

2. PHP はカプセル化機能が弱いため、フレームワークの柔軟性が不十分です
これも当てはまりますが、一般に、適切なフレームワークを選択するにはプロジェクトを評価する必要があります。単純な Web プロジェクトの場合、通常は CodeIgniter や CakePHP などのフレームワークを選択します。大規模なアプリケーションの場合は、Zend と CodeIgniter の使用はまったく異なるものであることがわかるため、Zend や Symfony などの大規模なフレームワークも選択します。
私が言ったことは抽象的かもしれませんが、例を挙げてみましょう。デフォルトの PHP 環境には AOP 関数がなく、クラスの既存のメソッドを機能拡張することができません。同様の関数を実装する必要があります。外部コードを明示的に変更する必要がある場合、非常に一般的な方法は PHP のマジック関数を使用することですが、それでもオブジェクトの作成方法を変更する必要があります。
それでも Ruby と比較すると、AOP サポートがほぼ組み込まれており、外部呼び出しを完全に変更せずに機能拡張を完了できます。
この機能の違いは、フレームワークのカプセル化においてさらに顕著になります。PHP のフレームワークは複雑であるため、ユーザーにとっての困難も増大します。また、その複雑さは、Ruby のようにフレームワーク内に完全に隠すことはできません。 (余談: 同じことが JavaScript にも当てはまり、jquery がその証拠です)。

?

3. PHP の実装メカニズムにより、フレームワークのパフォーマンスが批判的になります。
PHP の動作モードでは、各リクエストの終了時にすべてのリソースが完全に解放されるため、フレームワークのロードがパフォーマンス上の負担となります。無視しても構いませんが、前述したように、大規模なフレームワークを使用すると複雑さが増すため、中小規模のプロジェクトでは Zend などの大規模なフレームワークを簡単に使用できません。また、フレームワークの機能も制限されます。

私の分析によると、非常に多くの PHP フレームワークが存在するにもかかわらず、どれも真の主流にはなっていないのは、次の 3 つの理由によると考えられます。この状況は必ずしも良いことではありません。Rails の統合により、多くの Ruby 専門家がその機能を強化するためにさまざまなプラグインを開発しました。非常に健全な発展を遂げています。 jquery も js フレームワークで同じエクスペリエンスを持っています。
PHP では、専門家が常に新しいフレームワークを提供していますが、個人的には、その支援は非常に限られており、実際には 100 個のフレームワークを 1 つの開発に統合することはできません。 60 点のフレームワークは 100 点のフレームワークほど優れていません。 PHP フレームワークはたくさんあるので、傷つけるわけにはいきません。 ?