ホームページ >バックエンド開発 >PHPチュートリアル >PHP フレームワークと Ruby/Python フレームワークの違い_PHP チュートリアル
PHP フレームワークと Ruby/Python フレームワークの違い_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 10:33:51931ブラウズ
PHP: 各 HTTP リクエストが受信されると、すべてのリソースが初期化され (データベース リンクの作成、システム ライブラリのロード、キャッシュの作成など)、処理が完了すると、すべてのリソースが解放されます。
Python/Ruby: 初回起動時にリソースを初期化するため、後続のリクエストでリソースを再度初期化する必要はありません。
PHP と Python/Ruby のメカニズムの違いは次のとおりです:
- PHP で深刻なメモリ リークが発生することは非常に困難です。コードがどれほど悪くても、各リクエストが実行されるとすぐにすべてのリソースが解放されます。 Python/Ruby はメモリを再利用するために GC に依存する必要があるため、注意しないと、GC では解決できないメモリ リークの問題が依然として発生します。
- PHP はリクエストごとにリソースを初期化する必要があり、非常にコストがかかります。そのため、PHP パーサー自体は非常に高速に動作しますが、一度複雑な PHP フレームワークを使用すると、リクエストが行われるたびにフレームワーク全体を初期化する必要があり、非常に複雑な PHP フレームワークを使用した結果、パフォーマンスが大幅に低下するだけです。全体的なパフォーマンスは Ruby にはるかに及ばない。これが、PHP コミュニティが長年にわたってフレームワークを使用することにあまり関心がなかった理由の 1 つです。
- リクエストごとにリソースを初期化する PHP のメカニズムにより、PHP が高度なクロスリクエスト機能を追加することも非常に困難です。これは PHP 自体の大きな制限ですが、逆に言えば、この制限が PHP を常に A に保つ原因となっています。これが、PHP がインターネット上で最初の Web プログラミング言語になった理由であり、必ずしも悪いものではありません。
つまり、PHP と Ruby の違いは依然として非常に大きく、実際には、比較するのは Ruby と Python であるべきです。
つまり、Rails のフレームワーク アプローチが PHP に引き継がれた後、実際には PHP を間違った道に導いたと私は考えています。そのため、Rails が PHP の開発を誤解させていると言ったほうがよいでしょう。ちなみに、DHH は Basecamp を書く前は PHP を使用していて、Ruby に切り替えた後も PHP 用の高速開発フレームワークを作成しました。このフレームワークは実際には Rails のオリジナルのプロトタイプです。では、なぜ DHH は PHP に基づいて Rails を直接作成しなかったのでしょうか? Rails をリリースする前に Ruby に切り替える必要があったのでしょうか? PHP の動作メカニズムを見ると、PHP が複雑な Web 開発フレームワークを構築するのは明るい道ではないことがわかります。
PHP と PHP フレームワークのどちらを選択するかは、アプリケーションを満たすかどうかに基づいて決定する必要があります。フレームワークのパフォーマンス指標がアプリケーションを満たすかどうかを事前に決定します。テスト中に、さまざまなキャッシュ テクノロジのオンとオフを切り替える必要がある場合があります。アプリケーションのアーキテクチャをシミュレーションして設計し、フレームワークの適切かつ適切な採用を決定する必要があります。アプリケーションとは別に、どの言語やフレームワークが良いか悪いかを比較することに慣れている人もいますが、これが行き詰まりに陥ることが多いと思います。問題と向き合わなければ、問題の解決策を語ることはできません。技術的ソリューションはすべて、特定のアプリケーションの開発を目的としています。そうじゃない？
PHP の父であるラスムスも、PHP フレームワークが好きではないことを明らかにしました (ラスムス:「フレームワークは好きではありません。PHP フレームワークはとんでもなく遅いです」)。これはラスムスがスピーチで述べたことです。難しい。
PHP のような言語の場合、「各リクエストは完全なライフサイクル」であり、それ自体がシンプルさと反フレームワークを追求します。大規模な PHP インターネット アプリケーションは、Java/C++ を使用してバックグラウンドでミドルウェアを作成し、複雑なビジネス ロジックの処理を完了します。 PHP をフレームワークにすることは、PHP が負うべき責任ではありません。 (Drupalについて言及しましたが、フレームワークではなくプロダクトとしての位置づけなので、ここでは詳しく説明しません。)
製品の観点から見ると、Python の CMS Plone が最高であり、非常に強力な機能を備え、二次開発が容易で、Drupal のようなパフォーマンスの問題もありません。 Shanghai Runpu は、上海航空のようないくつかのシステムを含む、いくつかの商用プロジェクトの開発に plone を使用しました。
しかし、問題は、Python コミュニティにおいてさえ、高度に製品化された zope/plone が徐々に主流ではなくなり、主流のテクノロジーが django に移ってきたことです。したがって、反 PHP である Drupal のようなものがどれほど有望であるかを言うのは難しいと思います。
フレームワークを設計するとき、統合は良いことですが、過度の統合によって引き起こされるリソースの浪費と開発上の不都合が、一部のフレームワークが開発プロセスの簡素化につながる原因となることがあります。フレームワークを使用してプラグイン開発手法を使用します。これがフレームワークの実際の製品化です。シンプルさの美しさは美しさですが、多くのフレームワーク設計者は、フレームワークをシンプルにすることが非常に難しいことも認識しています。