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