異なるプロジェクト、異なる PHP

プロジェクト

Web プロジェクトにおける PHP の長所と短所に関するホームページの記事を見たので、いくつかのナンセンスを共有したいと思いました。

実際、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 言語の問題だけでなく、周辺開発の問題も含まれます。 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 を、いくつかのビジネス ロジック コンポーネントを配置するには ejb コンテナを使用できます。PHP は、これらを迅速かつ柔軟に結び付けるためのフロントエンドとシステムの間の接着剤として機能します。