PHP は優れたツールであり、単純なものも複雑なものもあります。プロジェクトごとに異なる PHP を使用する必要があります。
小規模プロジェクト - シンプルで直接的な PHP
一般に、機能ページが 20 未満の Web サイトの場合は、非常に単純なフレームワーク構造を使用して作成できます。この規模では、より直接的なプロセス指向のコーディング方法を使用することをお勧めします。その理由は非常に単純です。その結果、コントローラー内に新しいクラス ファイルは 1 つだけになります。もちろん、頻繁に要件が変更されるプロジェクトは除外されます。
このレベルでは、PHP の利点は明らかです。開発が迅速で、一目で明らかです。欠点もしっかり隠されています。
中規模プロジェクト - 美しく構造化された OO PHP
中規模プロジェクトの場合は、適切に設計されたフレームワークを使用することをお勧めします。このフレームワークは MVC モデルに基づいており、もちろん、多くの基礎となる操作をカプセル化します。変更に適応するために追加する OO メカニズムがより高速かつより適切に実行できるように、優れた、できれば透過的なキャッシュ メカニズムが存在する必要があります。
このレベルで。不完全な OO サポート (この PHP5 は大幅に改良されています) やシングルスレッド モードのみなど、PHP の欠点が明らかになり始めました。さらに、一部の周辺ツールはサポートが不足し始めています。たとえば、PHP には優れたリファクタリング ツールがなく、IDE に統合された優れた単体テスト ツールもありません。もちろん、利点は独自の迅速な開発と利用可能な幅広いオープンソース リソースです。
大規模プロジェクト - 拡張および最適化された PHP
ここでの大規模プロジェクトとは、単に分散プロジェクトを指します。つまり、プログラムを N 台のサーバーにデプロイする必要があります。このレベルでは、PHP は j2ee に比べて多くのサポートが不足しています。 PHP を大規模システムに適用するために解決する必要があるいくつかの問題について、shadow on 735 で詳しく説明しました。 もちろん、これらの問題には PHP 言語の問題だけでなく、周辺開発の問題も含まれます。
1 PHP ページ コードの共有。PHP ソース コードは一度メモリにロードされた後、メモリ内に保持されます。これは、APC と Zend のオプティマイザを使用して実行できます。
2 PHP ページ間でのデータ オブジェクトの共有、a.php と b.php は配列などのデータ オブジェクトを共有できます。これはシリアル化を使用して実行できるようになりましたが、ファイル IO が存在し、共有メモリを使用できます。または memcached を処理します。
3 PHP データベース接続プール。複数のフロントエンドの場合、PHP はデータベースへの接続を制御できないため、データベースの前に sqlrelay に似た接続プールを作成する必要があります。さらに、データのキャッシュも非常に重要です。プレッシャーのかかる開発には、できる限りデータベースに触れないようにするというヒントがあります。
4 PHP フロントエンド キャッシュ システム。透過的で制御可能なキャッシュ メカニズムにより、Web サイトのページがデータベースにクエリを実行する回数が最小限に抑えられます。これの実装はたくさんありますが、特に優れた実装は見つかりませんでした。
5 PHP アプリケーションがこれらの問題を正常に解決すれば、多少大きなプレッシャーにも問題なく対処できるようになります。
このレベルでは、PHP、java、C++、pythonなどを統合して効率的なシステムにすることが重要です。分散メモリ管理には memcached を、フルテキスト検索には Lucene を使用し、PHP はフロントエンドとシステムの間の接着剤として機能し、これらを迅速かつ柔軟に結合できます。