複数の PHP フレームワークの長所と短所のまとめ-PHPチュートリアル-php.cn

この記事は、複数の PHP フレームワークの長所と短所をまとめたものです。一定の参考価値があります。困っている友人は参考にしてください。お役に立てれば幸いです。

長い間、phper で最も議論されてきたのは、さまざまな php フレームワークの長所と短所でした。インターネット上の情報も比較的散在していました。今回は、主流のフレームワークをいくつか収集してまとめました。私は Yii2、Laravel、Yaf.、Thinkphp、この 4 つのフレームワークしか使ったことがないので、各種フレームワークの評価はネット上の情報がほとんどですが、問題がある場合はコメントで指摘して一緒に進めていきましょう。

1. ThinkPHP

ThinkPHP (FCS) は、Java の Struts 構造から移植された中国の PHP 開発フレームワークである、軽量の中規模のフレームワークです。オブジェクト指向開発構造と MVC モードを使用し、Struts タグライブラリの実装をシミュレートするため、あらゆる面でより使いやすくなっており、J2EE に慣れている開発者にとっては比較的簡単に始めることができ、J2EE の初心者にも適しています。 PHP フレームワーク。 ThinkPHP の目的は、開発を簡素化し、効率を向上させ、拡張しやすいことです。そのデータベースサポートには、すでに MySQL、MSSQL、Sqlite、PgSQL、Oracle、および PDO のサポートが含まれています。 ThinkPHP には豊富なドキュメントとサンプルがあり、フレームワークは高い互換性を持っていますが、機能が制限されているため、中小規模のプロジェクトの開発に適しています。

利点

1. 成熟したJavaのアイデアの助けを借りて

2. 使いやすく、豊富な中国語ドキュメント、低い学習コスト、高いコミュニティ活動

3. フレームワークには強力な互換性があり、PHP4 と PHP5 は完全な互換性があり、UTF8 を完全にサポートします。

4.小規模および中規模のプロジェクトの開発に適しています

5.thinkphp3.2.2のcomposerパッケージ管理ツールの導入

欠点

1 .Ajax サポートがあまり良くない;

2. ディレクトリ構造がわかりにくく、他のフレームワークに比べて少し悪い;

3. 始めやすいが、深く学ぶのは難しい。

2. Yii

Yii は、大規模な Web アプリケーションを開発するための、コンポーネントベースの高性能 PHP フレームワークです。 Yii は厳密な OOP で書かれており、完全なライブラリリファレンスと包括的なチュートリアルが含まれています。 MVC、DAO/ActiveRecord、ウィジェット、キャッシュ、階層型 RBAC、Web サービスからテーマ、I18N および L10N まで、Yii は今日の Web 2.0 アプリケーション開発に必要なほぼすべてを提供します。実際、Yii は最も効率的な PHP フレームワークの 1 つです。
#利点

1. 純粋なOOP

2. 大規模なWebアプリケーションに使用されます

3. モデルは使いやすい

4. 迅速に開発し、迅速に実行します。優れたパフォーマンスと豊富な機能

5. コマンドラインツールを使用します。

6. Composer パッケージ管理ツールのサポート

欠点:

1.モデル層のガイダンスと考慮事項が少ない

2.ドキュメントのサンプルが少ない

3. 英語が多すぎる

4. PHP テクノロジーと OOP プログラミングの熟練度が必要です。

5. ビューは理想的なビューではありません。理想的なビューは単なる HTML コードであり、PHP コードは含まれません。

3. Laravel

利点
1. Laravelの設計思想は非常に高度で、さまざまな開発モデルTDD、DDD、BDDの適用に非常に適しています

2. サポートComposer パッケージ管理ツール

3. PHP の比較的新しい機能に加え、さまざまなデザインパターン、Ioc コンテナ、依存関係注入などが統合されています。

欠点
1. コンポーネントベースのフレームワークに基づいているため、比較的肥大化します

4. CodeIgniter

利点:

1.Code Igniter は「シンプルさは美しい」という原則を提唱しています。派手なデザインパターンや派手なオブジェクト構造はなく、すべてがとてもシンプルです。数行のコードを実行するだけで実行が開始され、さらに数行のコードが出力されます。「素晴らしいシンプルさ」の典型と言えるでしょう。

2. 構成がシンプルで、すべての設定が PHP スクリプトで構成され、実行効率が高い;

3. 基本的なルーティング機能を備えており、ある程度のルーティングが可能;

4. 予備的なレイアウト機能があり、一定レベルのインターフェイスの外観を作成できます;

5. データベース層は適切にカプセル化されており、基本的な MVC 機能を備えています。高速かつ簡潔、コードは多くなく、実行パフォーマンスが高く、

7. フレームワークはシンプルで使いやすく、学習コストが低く、ドキュメントは詳細です;

8.

欠点:

1. 実装自体は理想的ではありません。

2. 内部構造がわかりにくく、シンプルで使いやすいのですが、拡張性がありません。

3. モデル層をデータベース操作として単純に理解します。

4. フレームワークはやや単純で、小規模なアプリケーションのニーズのみを満たすことができますが、ニーズを満たす能力は若干劣ります。

評価:

一般的に、CodeIgniter を使用すると、シンプルで高速なアプリケーションを完成させることができ、同時に、ある程度のレイアウトを構築することができます。データ操作層は適切にカプセル化されており、CodeIgniter では複雑すぎる設計パターンがあまり使用されておらず、実行パフォーマンスとコードの可読性の両方が良好です。追加のライブラリに関しても、非常に優れており、シンプルで効率的です。

5. Zend フレームワーク

利点:

1. PHP5 の多数の新しいオブジェクト指向機能が適用されます: インターフェイス、例外、抽象クラス、SPL など。。これらを応用することで、Zend Framework は高度なモジュール化と柔軟性を実現します。

2.「インターフェイスのプログラミング」と「単一オブジェクトの責任」の原則に厳密に従います

3.公式制作、自主制作多くのライブラリを備えており、フレームワーク自体は多くのデザインパターンを使用して記述されています。アーキテクチャは非常にエレガントで、実行効率は中程度です。
#4. MVC デザイン、比較的シンプル

5. ルーティング機能があり、設定ファイルは比較的強力です (XML と php INI を処理できます)
#6. データベース操作に加えてモデル層を直感的にサポートできます (CodeIgniter や CakePHP より強力です)。新しく追加された Class

7.Cache は非常に強力で、フロントエンドキャッシュとバックエンドキャッシュの両方をサポートしています。バックエンドキャッシュは Memcache、APC、SQLite をサポートしています。、ファイルなど
#8. データベース操作機能が非常に強力で、さまざまなドライバー（アダプター）をサポートしています。

9. ドキュメントが非常に充実しており、国内コミュニティで非常に成熟しています

欠点:

1.MVC 機能完成度が比較的弱く、View 層が実装されているだけ（実装されていないのと同じ）で、フロントエンドページを強力に制御することができません。アプリケーションを作成するには、エントリファイルを含め、すべて自分で手動でビルドする必要があります。フレームワークを使用すると、開発者にはより高い要件が提示され、プロジェクトの開発コストが間接的に増加します

評価:
公式フレームワークとして、Zend Framework の野心は予見できます。ワンストップフレームワークサービスを提供するために多くの強力なクラスライブラリをカプセル化しながら、それらの開発チームは非常に強力で、非常に強力な製品を開発する能力を十分に備えています。したがって、Zend Framework には明るい未来があると基本的に確信しています。枠組みを改善するために。同様に、Zend Framework アーキテクチャ自体は比較的洗練されており、これは Zend 公式に多くの専門家がおり、設計コンセプトが比較的進んでいることを示しています。ビューレイヤー、自動化スクリプトなどの一部の機能は完全には実装されていませんが、これらはすべて依存しています。アップグレード

6. CakePHP

利点:

1. 設計手法やデータベース操作のアクティブレコード手法など、RoR に最も類似したフレームワーク

2. 設計レベルは非常に洗練されており、追加のライブラリはなく、すべての関数は純粋なフレームワークであり、実行効率も悪くありません

3. データベース層の hasOne 関数と hasMany 関数は非常に優れています強力で複雑な業務処理に比較的適している適している

4. ルーティング機能、設定難易度は中程度

5. 自動構築スキャフォールド (scaffold) が非常に強力で中規模アプリケーションに適している

6. 基本的にすべての MVC First level に実装されています

7. コマンドラインスクリプトを自動操作する機能があります

8. ドキュメントは比較的充実しており、学習コストは中程度の

欠点:

1.CakePHPは非常に複雑です。深刻な問題は、モデルがデータベース層の操作として理解されることです。これは、データベース以外の操作能力に重大な影響を及ぼします

2. キャッシュ機能がやや弱い
##3. コンフィグレーション機能がやや弱い

4. 大規模アプリケーションには適さず、中規模アプリケーションのみに適しています。小規模なアプリケーションの場合はコストがわずかに高くなります。

評価:
一般に、CakePHP フレームワークは PHP フレームワークの重要性を表しており、RoR の時代と代表であり、現在非常に重要な役割を果たしています。自作フレームワークは、画期的な製品である CakePHP メソッドを模倣しています。CakePHP は、RoR のアジャイル開発メソッドを明らかにし、データベース操作を唯一のモデルと見なしています。その設計アイデアは、迅速なアプリケーションとプロトタイプを開発するための優れたツールです。同様に、それはまた、 Web2.0 Web サイトの開発フレームワークとして選択する価値があります

7. Symfony

利点:

1. MVC

2 の 3 つの層を完全に実装します。 . $POST、$GET データ、例外処理、デバッグ関数、データ検出を含むすべてをカプセル化します

3 .強力なキャッシュ機能を含みます

4. クラスを自動的にロードし、さまざまなクラスを自由に定義できます
#5. 強力な言語サポート

6. 多くの強力なビューレイヤー操作があり、複数のファイルを部分的に含めることができます

7. 非常に強力な構成機能XML 構成を使用して、すべてのフレームワークとプログラムの実行動作を制御します。

8. 強力なマルチレベルのプロジェクトおよびアプリケーション管理が含まれています: プロジェクト --> アプリケーション --> モジュール --> アクション。 1 つのプロジェクトで複数のアプリケーションのニーズに対応し、各レイヤーは独自のクラスライブラリ、構成ファイル、レイアウトを定義できます

9. プロジェクトの作成、アプリケーションの構築、モジュールの構築、更新などの非常に強力なコマンドライン操作機能

10. Symfony を使用すると開発コストが大幅に節約され、複数人で共同作業する場合にも問題がないため、Symfony は間違いなく大規模で複雑なプロジェクトを開発するための最初の選択肢です。プロジェクトレベルのクラスでは、任意のモジュールを再利用でき、コードを大幅に再利用できます。

欠点:

1. 最大の問題は、スタイルの異なるオープンソースプロジェクトが多すぎることです。 Framework

2. Mojavi や Propel 自体が非常に複雑なため、Symfony の構造も非常に複雑で理解しにくいです。そして学習

3. キャッシュ機能は制御できません。開発中やデバッグ中に毎回キャッシュされます。キャッシュをクリアして再構築するには、symfony cc、symfony rc を実行する必要があります。

4. 効率はあまり高くありません、特にテンプレートの解析と設定ファイルの読み取りのプロセスには時間がかかります多くの時間がかかります

5. 学習コストは非常に高く、中国には成熟したコミュニティや中国語ドキュメントがありません

評価:
Symfony は間違いなくエンタープライズレベルのフレームワークだけです。 Java分野の強力なフレームワークと競合できるように見えるもの. 強力なものは当然学ぶのが複雑ですが、プロジェクト開発にも役立ちます. 当然、複雑なプロジェクトを扱うにはSymfonyを使用することをお勧めします. それだけの価値があると思います、その後のメンテナンスコストが比較的低く、再利用性が非常に高いです。同様に、Symfony をより複雑なインターネットプロジェクトに使用する場合は、データベースの配布の問題を考慮する必要があります。その後、Symfony に付属するデータベース操作層を放棄して、自分で定義する必要があります。もちろん、Symfony は任意のモデル層の構築をサポートしています

全体的なコメント:
上記のフレームワークはそれぞれに特徴があり、いずれもオープンソースプロジェクトですが、フレームワークの対象となるプロジェクトが異なります。中規模プロジェクト: CakePHP、Zend Framework、Laravel、Thinkphp

3. 大規模重量プロジェクト: Yii、Symfony、Laravel

上記の区分は絶対的なものではありません。フレームワークを十分に考慮する必要があります。ニーズの変化に応じて変更を加えるかどうかをプロジェクトごとに決定できないため、カスタマイズ可能でスケーラブルです。