Thinkphp、qeephp、cakephp、zendframework、symfony の比較_PHP チュートリアル

demon は、優れたフレームワークとは単なる少数のビジネス フローではなく、拡張可能で、豊富で、コレクションであり、個別である必要があると信じています。簡単に言えば、それはあらゆる事物の矛盾であり、解離したものと集合したものの両方である。

ボリュームカットイン:
1.5947KBZendFramework-1.7.8-minimal16.1MBsymfony 1.2.511.1MB

注: 上記は削除する必要はありません doc、test、その他のファイルなどのファイルの最小サイズA大雑把な意見:

国内の枠組みは一般的に小さく、海外の枠組みは一般的に大きい - 。 。 ―ここでは単純に小さいことが良いと考えることはできません。

ディレクトリ構造:

thinkphp lib/org の下には、date、io、net、rbac、text などの一般的に使用されるツールがいくつかあります。 lib/think がコアで、

メインの mvc プロセス プラグインが適応プラグインです。 -in.

概要: 本当に小さすぎます。
一目ですべてがわかります。

demon は初心者の観点から thinkphp のプロセスを分析します:

最初に必要なファイル、共通、およびいくつかのクラスをコアの下にロードします。

new app() を呼び出して、

init で実行できます。 アプリが diapatcher をインスタンス化し、次に run と同様のメソッドを呼び出して、 アクション ルーティングを開始すると推測します。

qeephp
H QEEPHP のディレクトリ構造を見てください。これは非常に快適で、レベルが非常に明確です。 各フォルダーは機能ドメインに対応しています。 各ファイルには対応する例外があります。
command コマンド ライン ショートカット
extend での動作がモデルにバインドされていることを指摘することが特に重要です。
デコレーションモードとも言えます。
qeephp では、スケーラビリティ、
単一責任を満たすためにいくつかの設計パターンが使用されていることがわかります。
qeephpの起動方法。 。
まだ見つかりません。
これは単一責任の利点によるものです。
公式ドキュメントを参照:
参照:
// アプリケーションの起動情報を取得
$app_config = require(dirname(__FILE__) . '/../config/boot.php');
// 起動情報に従って設定QeePHP フレームワークとアプリケーション オブジェクトを作成します
require $app_config['QEEPHP_DIR'] '/library/q.php';
require $app_config['APP_DIR'] '/myapp.php';
// アプリケーション プログラムを構築します。オブジェクトを作成して MVC モードを開始します
echo MyApp::instance($app_config)->dispatching();
とても快適です。 。 。
しかし、合理化だけでは十分ではなく、
特に myapp.php と次の MyApp::instance($app_config)->dispatching();
との関係は非常に調整されていません。 (作成者の意図は、複数のアプリケーションと展開モードに対して複数のポータルを用意することだと思います
しかし、ポータルはファイル名ではなくインデックスを認識する必要があります)
例:
//設定に従って QeePHP フレームワークをロードします起動情報とアプリケーションオブジェクトに
require $app_config['QEEPHP_DIR'] '/library/q.php'
// アプリケーションの起動情報を取得します
$app_config = qee_App::getConfiguration("myapp");アプリケーション オブジェクトを構築し、
MVC モードを開始します
qee_App::createInstance($app_config)->dispatching();
これは良いことではないでしょうか?
面倒な手動ロードはありません。
実行したいアプリの名前を知るだけで済みます。
要約:
現在のディレクトリ構造から qeephp を学習できると言えます。
もちろん、まだ問題はいくつかあります。 E ディレクトリ構造の点では、QEEPHP が ThinkPHP

Cakephp


cake よりも優れていることがわかります。 興味深いことに、
空のアプリ プロジェクト ディレクトリ。
コアは 4 つのキャッシュ、コントローラー、モデル、ビューで構成されます。これは実際には MVC です。 。 。 非常にシンプルですが、シンプルすぎます。

cakephp は、基本的な MVC アプリケーションを初期化するための cli を提供します。

起動方法はqeephpと似ています。 zend
dZend にはサムネイルが必要ですが、
多すぎて大きすぎます。
zend は明らかに非常に明確で、
qeephp、symfony、
よりも明確で、非常に完全です。 特徴は、フォルダーだけで特定のタスクを完了できることです。

これにより、すべてのクラスを個別に分離できます。

外部のphpファイルはカプセル化されます。 対応するディレクトリは、クラスに含まれるクラスです。 組み合わせモードを使用して、組み合わせる 。
Zend の起動方法は馴染みのないものです。
でも、それは悪いことではないはずです。

symfony


symfony の構造も比較的明確ですが、その粒度はzend よりも繊細です。
コントローラー、レスポンス、リクエストを分離します。
しかし、全体的には zend よりも劣っており、
は十分に包括的ではなく、
は十分に離散的ではありません。 symfony の一部のコンポーネントには

特定の依存関係があります。

概要:
審査基準:

1.ディレクトリ階層は明確ですか

2.ディレクトリによって伝えられる意味がその固有のクラスと一致しているかどうか

3.ディレクトリ構造の一貫性

ディレクトリの観点から、zend>symfony>qeephp>cakephp>thinkphp

クラス図

thinkphp

コアクラス図から、baseから派生した単一ルート継承がわかります。 think のほぼすべてのクラスは Base から継承します

Util のクラス図はすべて Base から来ています。 thinkphp の構造を説明するために、単純な階層関係を使用します。この構造はベースを中心に外側に放射状に広がっています。

qeephp

EA のルート クラス図を見てください。これは単なる Q ですが、それがどれほど快適であるか、他のクラスではパターンのためにパターンを使用していません。

写真を見てください:

ほら、関係のない単一のクラスがあり、アプリケーションコンテキストを管理するために context などのクラスを使用しています。これは良い設計アイデアです。 symfony に基づいている必要があります。それは後で分析されます。

qeephp のクラス階層は自由で分散していると言えます。

symfony

クラス図の生成には 8 分かかりました。それがどれほど巨大であるかがわかります

ORM 層プラグインを削除します (symfony の mvc、m はプラグイン プラグイン、prop または doctrine によってサポートされています)

アプリケーションのプラグインメカニズム symfony は柔軟に変更できます。

も無関係な単一クラスであり、派生を通じて異なる設定ファイルを読み取ります。

Symfony は多くの場合に導出を使用します。構成されたドライバーは sfcontext によって均一に駆動され、sfconfig によって均一に管理されます。優れたアーキテクチャと単一の責任により、複数のクラスが sfcontext によって駆動される MVC ビジネス フローを完了できます。

sfcontext の場所は、基本スイートである util です。つまり、mvc モードを実行する必要がない場合は、sfcontext のディスパッチャーやコマンドラインモードを呼び出すことなく、実行コンテキストを作成するだけで済みます。メソッドと呼ばれるもの。

エレガントでシンプル、乱雑ではありません。

コンテキスト クラスは、mvc で使用する必要があるすべてのコンポーネントを管理します。

zend

同様にエレガントでシンプルですが、コンテキストを使用してすべてを管理します。

zendは大きすぎるので写真は載せません。

cakephp

cakephpには何も言うことはありません。本当に弱すぎます。 Demonではthinkphp、qeephp、cakephpに分類しています。

時間が迫っており、予備的な比較を完了するまでに 3 時間かかりました。もちろん自分に合ったものが一番良いです。

symfony と zend はデーモンに適しているため、視聴者は自分で決めることができます。

概要:

http://www.bkjia.com/PHPjc/735141.html

www.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/735141.html技術記事 Demon 氏は、優れたフレームワークとは、単にいくつかのビジネス フローを完了することではなく、拡張可能で、機能が豊富で、集約され、個別である必要があると信じています。簡単に言えば、それはすべてのものの矛盾です...