PHP開発フレームワークの現状と展望_PHPチュートリアル

Ruby on Rails がもたらす変化

RoR が普及する前、PHP 分野には Mojavi、WACT、PHPMvc、Seagull など多くの開発フレームワークがありました。これらのフレームワークでは、MVC パターンやデータベース抽象化レイヤーなどのテクノロジーも採用されています。しかし、PHP自体が今ほど普及していなかったために、これらのフレームワークは広く使われず、やがて沈黙してしまいました。

RoR による迅速な開発能力を実感した後、PHP コミュニティに刺激剤が注入されたように思えました。さまざまな応用技術や開発フレームワークが無限に登場します。

新世代のフレームワークの誕生

RoR に衝撃を受けた後、PHP コミュニティはあまり大きな論争に巻き込まれませんでした。その代わりに、私たちはすぐに行動を起こし、新世代のフレームワークの設計を開始しました。最初に登場した最初のフレームワークは、ほぼすべて RoR のクローンでした。たとえば、PHP on Trax (名前も Ruby on Rails から借用しています)、TaniPHP、Akelos などです。これらのフレームワークの最大の特徴は、アーキテクチャ、設計パターン、使用方法に関係なく、RoR を 100% 複製することを目指していることです。

これらのフレームワークは最初は開発者の注目を集めましたが、開発者がフレームワークをより深く知るにつれて、これらのフレームワークに対する後光は徐々に薄れていきます。アーキテクチャが曖昧で、パフォーマンスが低く、制限が多すぎるため、これらのフレームワークを実際のプロジェクトで使用するのは困難です。

現時点では、多くの PHP 開発者は RoR の設計アイデアから学ぶことができると信じていますが、RoR の構造と実装をコピーすべきではありません。このため、迅速な開発を促進するいくつかのフレームワークが PHP コミュニティに登場し始めました。これらのフレームワークの中で、CakePHP と Symfony が最適です。

CakePHP

CakePHP は、ActiveRecord モードからビューのレイアウト管理まで、RoR の影が満載で、RoR に非常によく似ています。そして、CakePHP は当初、RoR と同じことの多くを実装しようとしました。しかし、CakePHP の開発チームは、PHP 言語と Ruby 言語の間には大きな違いがあることを発見しました。そのため、RoR のデザインの多くは PHP で実装できたとしても、実用的な価値がありません。

CakePHP は、開発において RoR の影から徐々に抜け出し、PHP 言語自体の利点をより良く活用できるアーキテクチャと実装を模索し始めました。そのため、一時期、CakePHP の API が大幅に変更され、他の開発者は立ち止まって様子見することになりました。

しかし、初期のいくつかのアーキテクチャの無理とRoRの模倣が多すぎるため、CakePHPのコア部分はますます理解しにくくなり、動作パフォーマンスも満足のいくものではありません。さらに、CakePHP はすべてのビジネス オブジェクトの基礎として巨大なデータベース操作オブジェクトを使用します。これは迅速な開発に役立ちますが、ビジネス ロジック オブジェクトのテストが非常に困難になります。

小規模なプロジェクトの場合は、CakePHP が最適です。優れた迅速な開発機能、豊富な API、詳細なドキュメントにより、開発者は作業を迅速に完了できます。しかし、プロジェクトのサイズが大きくなるにつれて、CakePHP の制限も顕著になります。

Symfony

Symfony は、既存のオープンソース プロジェクトを広範囲に利用する非常に成熟したフレームワークです。 Symfony は Mojavi のコア コードを使用してフレームワークの MVC パターンを実装し、データベース抽象化レイヤーとして Propel を使用します。 Symfony は強力であるだけでなく、Ajax を包括的にサポートしています。公式 Web サイトで提供される大量のドキュメントとチュートリアル、活発なコミュニティと相まって、多くの開発者の間で人気があります。

しかし、Symfony の最大の問題は、フレームワークを形成するために、さまざまなスタイルを持つオープンソース プロジェクトが多すぎることです。 Mojavi と Propel 自体が非常に複雑であるため、Symfony の構造も非常に複雑で、理解して学習するのが困難です。

ただし、内部システムインフラストラクチャとしてフレームワークを選択したいと考えている企業にとって、Symfony の成熟度、豊富なドキュメント、および活発なコミュニティは検討する価値があります。結局のところ、企業の内部システムは安定性と長期サポートをより重視します。

商業的利益とシンプルさ

PHP 開発フレームワークの潜在的な商業的価値を認識した後、Zend.com と IBM は、PHP を真に活用できる開発フレームワークを立ち上げると発表しました。しばらくの間、このニュースは PHP コミュニティ全体に激震を引き起こしました。 「公式」の背景を持つこの開発フレームワークが PHP 開発者に正しい道を示してくれることを誰もが期待し始めています。

しかし、事態は予測不可能です。Zend Framework チームがいくつかのコード スニペットをリリースした直後、開発者はこれらのコード スニペットは実装不可能であると指摘しました。これらのコード スニペットは単なる美しい理想にすぎないことがわかります。 PHP 言語自体の機能による制限により、Zend Framework は最終的に、当初提供すると約束していた RoR での ActiveRecord モデルの実装を実現できませんでした。

Zend Framework

Zend Framework は、PHP5 の新しいオブジェクト指向機能 (インターフェイス、例外、抽象クラス、SPL など) を広範囲に適用します。これらを適用すると、Zend Framework は高度にモジュール化され、柔軟性が高まります。同時に、Zend Framework は「インターフェイスのためのプログラミング」と「単一オブジェクトの責任」の原則を厳密に遵守しているため、優れたエンタープライズ アプリケーション開発フレームワークになることが期待されています。

しかし、残念なことに、Zend Framework は今日までこれ以上の進歩を遂げていません。 Zend Framework を使用して開発する場合、フレームワークはアプリケーション自体の最も重要なドメイン ロジックを分離するのに役立ちません。本当に堅牢なエンタープライズ アプリケーションを開発したい場合、開発者は依然として多大な努力を払い、Zend Framework 上に独自のインフラストラクチャを構築する必要があります。

この点に対して、批評家は、Zend Framework は PHP5 の多数の新機能を適用しているものの、PHP4 に対するこれらの利点を開発者を支援できるものに変換していないと指摘しています。

単純で小規模なプロジェクトの場合、Zend Framework は開発効率を向上させることができないだけではありません。それどころか、多数のオブジェクト指向設計と PHP5 の新機能がフレームワークに適用されているため、開発者にはより高い要件が提示され、間接的にプロジェクトの開発コストが増加します。大規模なプロジェクトやエンタープライズ アプリケーションの場合、Zend Framework は優れた基盤となります。しかし、成功するアプリケーションを作成するには、依然としてかなりの努力が必要です。また、Zend Framewok のパフォーマンスの問題には常に注意を払ってください。

Code Igniter

Code Igniterはダークホースとも言えます。 Code Igniter は、Symfony と CakePHP が普及し、Zend Framework が大いに期待されていた時期に登場しました。しかし、Code Igniter はそのユニークな設計アイデアにより、多くの開発者を魅了しました。これは人気の公式フォーラムから確認できます。

Code Igniter は「シンプルさは美しい」という原則を提唱しています。派手なデザインパターンや派手なオブジェクト構造はなく、すべてがとてもシンプルです。数行のコードを実行するだけで実行が開始され、さらに数行のコードが出力されます。日常の開発で使用するもののほとんどは、すぐに利用でき、簡単に使用できます。 Code Igniter は「素晴らしいシンプルさ」のモデルと言えます。

ただし、Code Igniter の実装自体は理想的ではありません。内部構造がわかりにくく、シンプルで使いやすいのですが拡張性がありません。したがって、1.5 シリーズに開発する場合、作成者はさまざまなフックを追加してフレームワークに拡張機能を提供する必要がありました。

国産のPHP開発フレームワーク

過去に国内の開発者がいくつかのフレームワークをリリースしていますが、これらのフレームワークはシンプルすぎるか、特定の種類のアプリケーションと密接に結合していて汎用性に欠けています。 2006 年になって初めて、中国では多数のアプリケーションと PHP の人気が高まり、本格的な国内の PHP 開発フレームワークが徐々にリリースされました。

FCS

FCSは、JavaのStruts構造から移植された中国のPHP開発フレームワークであり、オブジェクト指向開発構造とMVCモードを使用し、特にJavaのいくつかの優れた外国のアイデアを利用してStrutsタグライブラリをシミュレートします。フレームワークであるため、Java に精通している開発者にとっては、そのテンプレート エンジン、キャッシュ メカニズム、認証メカニズム、およびスケーラビリティがすべて優れています。

FCS は海外の優れたアイデアから学びながら、国内のアプリケーション開発ニーズもより考慮しています。 PHP4 と互換性があり、UTF-8 を完全にサポートし、PATHINFO などをサポートするため、国内のホスト環境と開発ニーズにさらに適しています。 FCS は、使いやすさと拡張のしやすさの原則に基づいて、わかりやすいプロジェクト、モジュール、操作メカニズムに加えて、いくつかの組み込みの自動操作メソッドを使用して、基本クラス ライブラリやさまざまな機能を通じてアプリケーション開発を容易に実装できます。プラグインは、増大するビジネス ニーズに合わせて柔軟に拡張できます。 FCSは開発体制が整っているからこそ、大規模アプリケーションの開発にも障害が少なく、コンポーネントベースのアプローチとフレームワークと連携したプロジェクト管理の仕組みにより、大規模アプリケーションでも腕を振るうことができます。 -スケールアプリケーションが長い。

FCS は、国内の PHP 開発者の学習と習得に役立つ、コードの合理化と完全な中国語のドキュメントとコメントを目指しています。ただし、現在の状況によると、公式ドキュメントとコミュニティのサポートがまだ比較的不足しており、サポートはありません。 Ajax は包括的ではないため、国内のアプリケーションは十分に成熟していません。

FleaPHP

FleaPHPは、開発の観点から見て一定の歴史を持つフレームワークです。過去 3 年間で、FleaPHP は、PFC1 ～ PFC3 シリーズと、flea1 実験的フレームワークをリリースした後、著者が立ち上げた最初の真に成熟した安定した開発フレームワークです。

他の多くのフレームワークとは異なり、FleaPHP は、迅速な開発と PHP 自体の利点の最大限の活用という 2 つの焦点を中心に設計されました。したがって、FleaPHP の最大の特徴は、モジュール性と拡張性が非常に高いことです。

FleaPHP フレームワークのコアは非常に小さいですが、柔軟な構成により、さまざまな種類のインフラストラクチャを組み合わせることができます。単純なスクリプト ページの場合、FleaPHP は MVC モードをロードする必要はなく、アプリケーションにビジネス ロジックとデータベース サービスを提供するだけで済みます。複雑なアプリケーションの場合、FleaPHP は、MVC モードの呼び出し、アクセス制御、データ検証からファイルのアップロード、画像処理などのさまざまなタスクを完了できます。

この優れたカスタマイズ機能と拡張機能があるからこそ、FleaPHP は「単純なアプリケーションからエンタープライズ開発まで、さまざまなニーズに応える」という目標に真に近づくことができるのです。また、他の多くのフレームワークとは異なり、FleaPHP は実際の開発中に完全に改良されるフレームワークです。そのため、FleaPHPの開発により、さまざまな実用的なアプリケーションが次々と登場しています。 FleaPHP 公式 Web サイトでは、さまざまな実践的なアプリケーションをご覧いただけます。最も単純な企業プロモーション Web サイトから、複雑なコミュニティ Web サイト、企業内部システムなどまで、数多くあります。

FleaPHPは完全国産フレームワークとして、中国語のドキュメントやコードコメントが充実しており、拡張機能に関しても国内開発者の実際のニーズに配慮しています。したがって、FleaPHP は海外のさまざまなフレームワークと比較して、国内の開発者に受け入れられやすいです。

しかし、まさに中国にあるからこそ、FleaPHP は海外の同等製品よりも多くの困難に直面しています。貢献者の不足、無礼な批判、懐疑的な目などにより、FleaPHP の開発チームのメンバーにはさらなる献身的な努力が求められています。また、十分な貢献者が不足しているため、FleaPHP フレームワークは現在、ドキュメントや拡張機能の点で他の成熟したフレームワークに後れを取っています。
そして、他のすべての PHP 開発フレームワークと同様に、FleaPHP は開発者がアプリケーション ドメイン ロジックを分離するのに役立つ方法を見つけていません。ガイダンス文書はありますが、ジュニア開発者にとっては、すぐに使用できるドメイン ロジックの基礎が非常に実用的です。

反省と進歩

RoR がもたらした衝撃はまだ収まっていませんが、PHP 開発者はすでに RoR の足跡を盲目的に追従することが本当に PHP 開発に質的な変化をもたらすことができるのかを熟考し始めています。

RoR がこれほど大きな成功を収めた理由は、RoR 自体の設計思想に加えて、RoR が Ruby という言語の強みを最大限に活かしていることも重要な理由です。 Ruby 動的言語の利点を最大限に活用してください。 PHP では、RoR のデザインをそのままコピーすると、PHP 言語自体の制限に遭遇します。これらの制限を回避するには、開発者はいくつかの理解できないトリックを使用して問題を解決する必要があります。しかし、そうすると、フレームワークの構造があいまいになり、パフォーマンスが低下することがよくあります。

この考察では、Code Igniter や FleaPHP などのフレームワークがこの質問に対する最良の答えです。 PHP 言語自体の利点を最大限に活用することによってのみ、PHP 開発は真に簡単かつ興味深いものになります。

現在、さまざまな PHP 開発フレームワークがそれぞれ独自の特徴を持っていますが、ほぼすべてのフレームワークが開発効率の向上を目指しています。しかし、これらのフレームワークの中には、アプリケーションの保守性を向上させるという問題に注目しているものもありますが、ドメイン ロジックの分離という重要な問題に対する解決策を提案したものはありません。そして、これがまさにこれらのフレームワークが将来進むべき方向です。

単純な Web アプリケーションと複雑なエンタープライズ アプリケーションの場合、この 2 つの違いは、固定されたアーキテクチャではニーズを満たすことができないことを意味します。したがって、カスタム アーキテクチャ機能を提供できる FleaPHP のようなフレームワークを使用すると、開発者はフレームワークのさまざまな組み合わせを試して、単純なものから複雑なものまでさまざまなレベルのニーズを解決できます。

将来、PHP は Web 開発の分野でますます重要なプラットフォームになるでしょう。したがって、より良い開発フレームワークがより多く出現すると私たちは信じています。ただし、開発者としては、問題を解決するために必ずしも特定のフレームワークを使用する必要はありません。しかし、まさにこれらの新しいフレームワークのおかげで、PHP を使用して Web アプリケーションを開発することに対する私たちの理解と把握が何度も促進されてきました。