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 言語の問題だけでなく、周囲の開発の問題も含まれます。
1 PHP ページのコード共有。PHP ソース コードは一度メモリにロードされた後、メモリ内に保持されます。これは APC および Zend のオプティマイザを使用して実行できます。
2 PHP ページ間でのデータ オブジェクトの共有: A.php と b.php は配列などのデータ オブジェクトを共有できるようになりましたが、これは共有メモリを使用して実行できます。または、それを処理するために memcached を実行します。
3 PHP データベース接続プール。複数のフロントエンドの場合、PHP はデータベースへの接続を制御できないため、データベースの前に sqlrelay に似た接続プールを作成する必要があります。さらに、データのキャッシュも非常に重要です。プレッシャーのかかる開発には、できる限りデータベースに触れないようにするというヒントがあります。
4 PHP フロントエンド キャッシュ システム。透過的で制御可能なキャッシュ メカニズムにより、Web サイトのページがデータベースにクエリを実行する回数が最小限に抑えられます。これの実装はたくさんありますが、特に優れた実装は見つかりませんでした。
5 PHP アプリケーションがこれらの問題を正常に解決すると、多少大きなプレッシャーにも問題なく対処できるようになります。

このレベルでは、PHP、Java、C++、Python などを統合して効率的なシステムにすることが重要です。分散メモリ管理には memcached を、フルテキスト検索には Lucene を、PHP はフロントエンドとシステムの間の接着剤として機能し、これらを迅速かつ柔軟に結合することができます。