PHP は誕生以来、大多数のプログラミング愛好家に愛されており、中小規模の Web マスターの優れた助けとなり、多数の PHP プログラマーを育成してきました。しかし、PHP のアプリケーションがますます普及するにつれて、多くの場合、小規模および中規模の Web サイトのアプリケーションに限定されず、大規模な PHP プロジェクトも一般的です。
大規模なプロジェクトを開発する際にPHPを選択する場合、開発効率や開発仕様、アフターメンテナンスなどを考慮する必要があるため、現在主流となっているような、誰もが認める開発フレームワークを選択することが多いです。 Zend Framework、Yii、Symfony、CodeIgniter、CakePHP などはすべて、大規模なアプリケーションを開発する機能を備えていると主張しています。
新しいフレームワークが次々と登場していますが、実際にそれらのフレームワークを適用してプロダクトを実装するとなると、必ず様々な問題が発生します
1. 大規模なフレームワークの背後には、多くの場合、深い構造理論が存在します。最もよく知られているのは、MVC や ORM などのよく知られた理論用語であり、詳細なオブジェクト指向の知識も数多くあります。これらを本当に理解している人がいないため、アプリケーションの敷居が大幅に上昇しており、さらに、大規模なフレームワークでのアプリケーションの詳細はさらに複雑になり、学習コストが比較的高くなっています。これは、当初ターゲットとしていた PHP にとって特に厄介なことになっています。小規模および中規模のアプリケーション。
2. スクリプト言語として、PHP はホスト プロセス (Apache、php-fpm など) に基づいて実行されることが多く、プロセスの作成、環境の初期化、スクリプトのコンパイル、エンジンの実行、出力、リソースのリサイクルなどを単一のプロセスで実行します。プロセス破壊などの一連の処理は、プログラミング言語レベルでの総合的な動作効率の点でコンパイル言語に比べて2～3桁遅く、また大量のシステムリソースを消費します。複雑な開発フレームワークを構築してロードする必要があるため、運用コストも増加します。大規模なアプリケーションでは、特殊なニーズが不足することはありません。PHP の大規模なフレームワークの動作効率が致命的な場合もあります。
3. 大規模なフレームワークでは考慮すべき要素が多すぎるため、開発者は適用時にコード以外の多くの詳細に特別な注意を払う必要があります。たとえば、非標準の規約、長いマニュアル、簡単な構成、複雑なファイル ディレクトリ構造などです。 、制限するのが難しい合理的な性的制約、さまざまなクラスライブラリなどにより、ほとんどのプログラマの開発プロセスは混乱しており、開発効率の向上は空虚な話になっています。
4. 最も致命的な点は、フレームワークの作成者が常に特効薬を探し、あらゆるニーズを満たすモンスターを作成しようとしていることです。大規模なアプリケーションでは、システムの疎結合に対する高い要件が必要です。通常、開発レベルでデータを直接操作することは不可能です。データ層とビジネス層はほぼ物理的に分離されています。ビジネス層 開発の観点からは、データ層によって提供されるサービス インターフェイスのみにアクセスします。現在の PHP 開発フレームワーク (特に MVC モデル) から判断すると、ORM は通常、データベース テーブルを直接抽象化し、CRUD 操作を直接実行するために使用されます。信頼性の高い大規模アプリケーションでは、これは行われません (VPS には適しているかもしれませんが、大規模なアプリケーションではありません)。 VPS を選択しますか??)。
要約すると、PHP 大規模フレームワークは実際には依然として恥ずかしい立場にありますが、その一方で、優れた PHP 大規模フレームワークは、多くの設計概念、設計パターンが含まれており、多くの人から学ぶ価値のある良い例です。 , コードの最適化、言語機能、ソフトウェア エンジニアリング、その他の知識システムは PHP の本質を統合していますが、PHP 自体をはるかに超えています。
最後に、これらの大規模な PHP フレームワークについてよく言われることわざを言わなければなりません。「学ぶ者は生き、使用する者は死ぬ」です。
引用元: Red Eye Technology Blog
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
