知り合いになってから、このフレームワークは興味深く、有望で、私にとって注目に値するように思えました。
Daniel Carreraは最近、CakePHP、CodeIgniter、およびYiiの比較に関する「PHPフレームワークの比較」という興味深い記事をブログに投稿しました。
ロシア語を話す（英語が読めない）人々の間でYiiを普及させるために、私は翻訳を行うことにしました。
注意：本当にたくさんの手紙があります。
-
内容
- シンプルさ
- ドキュメント
- 性能
- 柔軟性
- 安全性
- その他のコメント
- まとめ
-
シンプルさ
アプリケーションを作成する前にフレームワークの単純さを判断することは困難ですが、ドキュメントに基づいていくつかのコメントをすることができます。
Cakephp
インストール：文書化されていないApacheで問題が発生しています。 「RewriteBase」コマンドを追加するには、3つの.htaccessファイルを編集する必要がありました。
使用：ヘルパー、アクション、振る舞い、レイアウト、コンポーネント...プログラムを書くためには、これらすべてを本当に知る必要がありますか？ ケーキみたい
最高のエントリーしきい値であり、現時点では、他のフレームワークでは提供されない特別な機能はありません。
すべてのフレームワークには、デフォルトのレイアウトとCSSが付属しています。 テストの目的で、各フレームワークが必要なことだけを行うように、これを取り除く必要がありました。 CakePHPの場合、どのデザインファイルが使用されたかを見つけるのは非常に難しいことがわかりました。 それは非論理的な場所でした（私のアプリケーションディレクトリ内）。
CodeIgniter
インストール：簡単。 ファイルを解凍するだけで準備完了です。
使用法： CodeIgniterは十分に単純なようです。 ドキュメントには、それを疑う理由はありません。 私のhello-worldアプリケーションは、Cakeを使用する場合よりもはるかに高速に準備できました。 一般に、CIのエントリのしきい値は低くなります。
すべてのフレームワークには、デフォルトのレイアウトとCSSが付属しています。 テストの目的で、各フレームワークが必要なことだけを行うように、これを取り除く必要がありました。 CIの場合、これは新しいビューを作成したときに自動的に発生しました。 CIは、そうするように求められない限り、デザインを挿入しません。
Yii
インストール：簡単。 ルートWebディレクトリを作成するには、yiicを実行する必要があります。 PHPバージョン（yiic.php）もあり、sshにアクセスできない場合に適しています。 Yiicはよく文書化されています。
使用法： Yiiもシンプルでわかりやすいように見えます。おそらくCodeIgniterよりもやや少ないでしょう。 私の「ハローワールド」は、CIの場合とほぼ同じ速さで作成されました。
すべてのフレームワークには、デフォルトのレイアウトとCSSが付属しています。 テストの目的で、各フレームワークが必要なことだけを行うように、これを取り除く必要がありました。 Yiiでは、非常に簡単でした。 設計ファイルは論理的な場所にあり、十分に文書化されています。
Smartyなどのテンプレート言語を学ぶ必要のあるフレームワークはないことを報告できて嬉しいです。 PHP自体は優れたテンプレートエンジンです。 私は数年間Smartyを使用しましたが、率直に言って、メリットよりも問題の方が多いと思います。 YiiとCodeIgniterが付属していることに注意してください
特に好きな人のためのオプションのテンプレートエンジン。 しかし、私が言ったように、これはオプションです。
結果： CodeIgniterが最もシンプルで、Yiiがそれに続きます。
テストの2番目の部分でプロトタイプアプリケーションを作成するまで、最終判定を延期します。
-
ドキュメント
批判してください。 ドキュメントは通常、実際にアプリケーションを作成しているときに少し異なって見え始めます。 不正確または不完全な場合は、作業を開始するまでそのことを知りません。 これまで、テスト済みフレームワーク用に作成したアプリケーションはhello worldのみです。
Cakephp
私の第一印象はポジティブでした。 ドキュメントは完全で読みやすいように見えます。 チュートリアルを見つけるのはかなり困難でした（それらはサンプルアプリケーションのセクションで終わりました）。 「hello world」を書いたとき、問題（404エラー）に遭遇しましたが、これはドキュメントに記載されていませんでした。 これを解決するには、.htaccesファイルを編集する必要がありました。 ドキュメントの「トラブルシューティング」セクションを参照してください。 さらに、デフォルトでCakeに存在するローション（ヘッダー、フッター、スタイル）を取り除く方法を理解することは非常に困難でした。
CodeIgniter
第一印象は再びポジティブでした。 「hello world」を書くことは、Cakeよりもはるかに短い時間でした。 その理由は、CIの方が単純だからだと思いますが、ドキュメントが影響を与えていると思います。
Yii
繰り返しになりますが、私の最初の印象は肯定的で、ハローワールドを非常に迅速に書きました。 その後、Yiiがページをきれいにするために接続する追加のローションを取り除きました。 その方法を見つけるのは非常に簡単かつ迅速でした。
結果：現時点では、判断するのは難しいです。
すべてのフレームワークには優れたドキュメントがあるようです。 Cakeにはいくつかの問題がありましたが、今のところはっきりとは言えません。
-
性能
このパートでは、2つのパフォーマンステストについて説明します。 1つは私によって、もう1つはYiiチームによって行われました。 両方とも注目に値すると思います。
主な類似点：
両方のテストは、各フレームワークの最小オーバーヘッドを推定しようとします。 このフレームワークの目標は、「Hello World」をもたらすことです。
主な違い：
各フレームワークのデフォルト構成を使用しました。 Yiiチームは、各フレームワークを最適化して、Hello Worldをできるだけ早く表示しようとしました。
Yiiからのテストはdie（）のみを実行します。 MineはMVCを使用します。コントローラーは変数を「Hello World」に設定し、メインHTMLページで出力するためにビューに渡されます。
Yiiはテスト専用のサーバーを使用し、実際のアプリケーションをホストする共有ホスティングを使用しました。
そのため、Yiiチームのテストは技術的にはより正直ですが、実際の動作をよりよく反映しています。
いつものように、すべてのテストは批判的に行われるべきです。
結果は1秒あたりのリクエスト数（RPS）で表されるため、値が大きいほど優れています。
テストの詳細：
Yiiウェブサイトのこのページでは、テストについて説明しています。 私のテストでは、各フレームワークにはビューに次のコードが含まれていました。
変数$メッセージはコントローラーによって提供され、その値は「Hello World」です。 1秒あたりのリクエスト数は、ApacheBenchユーティリティと「ab -t 30 -c 10 URL」パラメーターを使用して決定されました。 私のテスト環境は、次のパラメーターを使用した共有ホスティングです。
* CentOS 4 Enterprise Linux。
* Apache 2
* PHP 5.2.6
* CPU：クアッドコアAMD Opteron（tm）プロセッサー2350
*メモリ：8GB
結論： YiiとCIはどちらも速度の点で際立っていました。 Yiiにはいくつかの利点があるかもしれませんが、確かに言うのは難しいです。
-
柔軟性
Cakephp
CakePHPは慣習に非常に関係しています。 彼はあなたにファイル、クラス、データベース、メソッドなどの特定の命名を期待しています。 今のところ、これが私にとって問題になるかどうかは言えませんが、これは起こる可能性があります。
CodeIgniterとYii
CodeIgniterとYiiはどちらも非常に柔軟に見えます。 ドキュメントを見ると、一方が他方よりも確実に柔軟であると言うのは問題です。
どちらもMVCパターンを使用しますが、この点に関しては厳密ではないようです。 CakePHPはYiiやCIよりもはるかに規約に依存しています。
類似点と相違点の例：
*各フレームワークでは、コントローラーの命名規則に従うことが期待されています。
* CakePHPは、プログラムで使用されていない場合でも、モデル、データベース、テーブルを作成する必要があります。
* Cake自体は、コントローラーの名前に基づいてビューを自動的に呼び出します。 CIおよびYiiでは、明示的にビューを呼び出すため、Cakeの規則が構成よりも優先されます。 また、CIおよびYiiでは、複数のビューを呼び出すことができます。
サンプルコードを次に示します。
ご覧のとおり、CIとYiiのバージョンはCakePHPよりも複雑ではないようです。さらに、追加機能があります-複数のビューファイルをアップロードできます。 たとえば、特別なヘッダーをロードしたり、ウィジェットを挿入したりできます。
結果： CodeIgniterとYiiはどちらもより柔軟に見えます。 現時点では、どちらがより柔軟かを判断することはできません。
-
安全性
さまざまな種類の攻撃が存在するため、セキュリティは複雑なトピックです。 この段落は非常に膨大ですが、このトピックに固執するようにします。 この段落は、フレームワークの機能と攻撃の種類に応じて部分に分けられます。
アクセス制御
ここでの予備情報- 認証と承認 。
Cakephp
CakePHPのアクセス制御システムは理解しにくいことがわかりました。 コードジェネレーター（「ケーキベイク」）を使用して、スキーマファイルとアクセス制御リスト （ACL）を生成します。このプロセスは複雑に見えます。 いくつかの用語（ACO、ARO、リクエスター）で完全に終了しました。
アクセス制御には注意が必要だと思っていましたが、Cakeでは予想以上に複雑でした。 とても強力に見えますが、使いにくいです。 私はプロセスをコントロールしていないと感じ、何が起こっているのか理解できませんでした。 そして、セキュリティはまさに私がコントロールしたいものであり、よく理解したいものです。
クイックテスト ： パスワードの強度を強化する方法がわかりません。 チュートリアルでは、自分でパスワードをハッシュすると、アプリケーションは機能しないと説明されています。
CodeIgniter
私が知る限り、CIはアクセス制御機能を提供していません。 アクセス制御は非常に困難なタスク（グループ、ロールなど）になる可能性があり、フレームワークがこれを助けてくれればいいと思います。
Yii
Yiiのアクセス制御システムの方がずっと早く理解できました。 簡単だとは言いませんが、これはアクセス制御自体が簡単ではないからです。 Yiiでは、アクセス制御システムは可能な限りシンプルですが、それ以上ではありません。 ドキュメントを読んだ後、プロセスを理解し、自分のニーズに合わせて変更できるように思えました。
クイックテスト ： パスワードの強度を高める方法をすぐに見つけることができました。
好きなYiiチップ
* 柔軟性：ユーザーのIPアドレスまたはリクエストタイプ（GETとPOST）に基づいたアクセスルール、または匿名ユーザーと許可ユーザーのルールを設定できます。
* リターンURL：リンクをたどりますが、セッションはすでに古くなっています。 ログインページにリダイレクトされます。 ログインすると、システムは自動的に目的のページに戻ります。 私にとっては、これは非常に便利です。
* ロールベースのアクセス制御 ： RBACは、従来のACLよりも柔軟で強力です。 Yiiフレームワークを使用すると、RBACに注意を払わずにアプリケーションを記述し、特定の問題を解決する必要がある場合にのみ使用できます。 したがって、システムは本来あるべき柔軟性を備えていますが、アクセスルールは必要なものよりも複雑ではありません。
辞書攻撃
辞書攻撃は、最も使用される単語のリスト-辞書-を使用してパスワードを推測しようとする試みで構成されます。 Webアプリケーションの場合、このような攻撃は非常に効果的です。 最近のTwitterへの攻撃は辞書攻撃でした。
辞書攻撃を終了させる方法は多数あります：Xが認証試行に失敗した後のアカウントのロックアウト、時間の遅れ、CAPTCHA。 それぞれに長所と短所があります。 アカウントのロックアウトは簡単で効果的ですが、サービス拒否を攻撃する機会を提供します 。誰かが多くの認証試行を行うことができますが、アクセスを得るためではなく、他のユーザーをブロックするためです。 私が気に入っている方法の1つは次のとおりです。5回失敗した後、追加の試行を取得するにはキャプチャを解決する必要があります。 これにより、辞書攻撃、DoS、および使いやすさを制御できます。
どのフレームワークにも辞書攻撃やサービス拒否の問題に関連するツールはありませんが、私はこれを期待していませんでした。 本当の問題は、 このフレームワークで承認方法を必要な方法で正確に構成できるかどうかです。 これは制御と柔軟性の問題です。 CIとYiiでは、これができると確信しています。 ただし、CakePHPでこれについてはよくわかりません。
クロスサイトスクリプティング攻撃（XSS ）
XSSは 、最も一般的なセキュリティ問題のランク付けにおいて、バッファオーバーフローを上回っています。 これは次のように機能します。誰かがブログにコメントを投稿し、この投稿に悪意のあるJavaScriptコードが含まれています。 ブログを閲覧すると、コードが実行されます。 コードはドメインから取得されるため、「安全な」ブラウザと見なされます。 このコードは、Cookieを読み取ったり、ページのコンテンツを変更したりできます（たとえば、「セッションの有効期限が切れました。パスワードを入力してください。」）。
CodeIgniterとYiiには、ユーザー入力からJavaScriptコードを削除できるHTMLフィルターが付属しています。 残念ながら、CakePHPにはそのようなフィルターはありません。
SQLインジェクション攻撃
SQLインジェクションは、Webアプリケーション（コミック）で最も一般的な攻撃とセキュリティ上の欠陥の1つです。 これは、ユーザーが入力したテキストが実行可能なSQLコードとして解釈される場合に発生します。 例：
ユーザーがパスワードfoo 'OR 1 =' 1を入力したとします。 その場合、リクエストは次のようになります。
1 = '1'は常にtrueであるため、クエリはすべてのユーザーのリストを返します。 最も一般的な（そして正しくない）解決策は、 addslashes（）やmysql_real_escape_string（）などの関数を使用して文字列をエスケープすることです。
この決定の何が問題になっていますか？
*パラメータごとにこれを行う必要があるため、エラーが発生しやすくなります。
*また、ハッキングに使用できるすべての文字を誰かが見つけることができるという事実にも依存します。 善人はすべての穴を見つけます、悪人はただ一つを見つけます。 これは敗者のためのゲームです。
Chris Shiflettは 、中国語文字を使用して、スラッシュをバイパスするSQLを注入する方法を示します。 mysql_real_escape_stringをバイパスできるタミル文字がないことをどのようにして知ることができますか？
正しい決定：準備されたステートメント
適切な解決策は、ユーザー入力とは別にSQLクエリをコンパイルすることによって、つまり準備済みの式（つまり、パラメーター化されたクエリ）を使用して問題全体を解決することです。 準備された式は、SQLクエリロジックをユーザーデータから分離します（ こちらとこちらをご覧ください）。
フレームワークは準備された式をサポートしていますか？
残念ながら、3つのフレームワークの1つ（Yii）だけがこのような機会を提供します 。 準備された式の欠如は、CakePHPとCodeIgniterの最も深刻な問題だと思います。
クロスサイトリクエストフォージェリ攻撃（CSRF ）
クロスサイトスクリプティング（XSS）攻撃に加えて、ある意味でクロスサイトリクエストフォージェリ（CSRF）が使用されます。 XSSはサーバーに対するクライアントの信頼を悪用し、CSRFはクライアントに対するサーバーの信頼を悪用します。 Bobが次の画像タグを含む悪意のあるサイトにアクセスしていると想像してください。
現在、ボブが銀行のページで承認されている場合、銀行サーバーはボブからEvaの口座に10,000ドルを転送するリクエストを受け取ります。
CSRFから保護するために何ができますか？ Cookieの有効期間を短縮することに加えて、主な解決策は、秘密の値を使用して、サーバー上のデータを変更できるGETおよびPOSTパラメーターを認証することです。
CakePHPとCodeIgniterには、CSRFと戦う手段がないようです。 Yiiは、シークレットトークンを使用してPOSTリクエストのCSRF保護を提供します（この機能を有効にする必要があります）。 CSRFから完全に保護するには、GETリクエストがサーバー上のデータを変更できないことを確認する必要があります。
Cookieの盗難 （ Cookieハイジャック攻撃 ）
Cookieは通常、セッション識別子、ユーザー名、パスワードハッシュなどの十分な意味のある情報を保存するために使用されます。 Cookieの盗難とは、第三者がお客様のCookieにアクセスすることです。 これは、XSSまたはパケットスニファーを使用して実行できます。
クッキーの盗難から身を守るには？ SSLはスニファーからユーザーを保護するため、XSS攻撃を防ぐための対策を講じる必要があります。 重要な情報を長期間保存することを拒否することで、Cookieの重要度を下げることができます。 たとえば、md5（passwd）を保存する代わりに、期限切れのハッシュ-HMAC（date、md5（passwd））を使用します。
私が知る限り、CakePHPとCIにはCookieの盗難に対する保護メカニズムがありません。 YiiにはCookieを検証する機能があり、HMACを使用して含まれるデータを認証します。 攻撃者は、気付かれることなく期限切れのCookieのデータ（有効期限など）を変更することはできません。
もちろん、あなたが愚かな間違いを犯した場合、これはすべてあなたを助けません-例えば、クッキーに平文でパスワードを保存します。
勝者 ：Yii
Yiiには、優れたアクセス制御とXSS保護、SQLインジェクション、クロスサイトリクエストフォージェリ、Cookie盗難など、セキュリティ上の大きな利点があります。
CakePHPとCodeIgniterは、この点で少しがっかりしています。 CIは柔軟性が高いため、必要なセキュリティ機能を自分で簡単に追加できます。
-
その他のコメント
言及する必要があると思われるものがいくつかありますが、それらはこのテストの基準に該当しません。
試作機
CakePHPはPrototypeライブラリを使用します。 プロトタイプを扱っていました。 基本的に、グローバルな名前空間を汚染し、すでに実行中のJavaScriptコードを壊す可能性があります。 したがって、Prototypeはコードや他のライブラリではうまく動作しません。
計画的リリース
Yiiには今後のリリースがあります 。 すべてのオープンソースプロジェクトにこれが欲しいです。
入力フィルタリング
CodeIgniterには、データをクリーンアップする優れたInputクラスがあります。 GET配列と、POSTおよびCOOKIEを除くすべてのグローバル変数を破棄します。 この機能は私の基準に完全には適合しませんが、コードの改善に貢献するため、言及する価値があります。 前のセクションでXSSフィルタリングについて言及しました。
-
まとめ
私の意見-CakePHPは間違いなくCIやYiiよりも悪いです。 ドキュメントは一般的に優れていますが、CIとYiiに勝るものはありません。 CakeがCIやYiiより明らかに良く見える領域は見当たりません。 Cakeが期待するとおりにすべてを行う単純なアプリケーションの場合は、より良いかもしれません。 しかし、一般的に、CakeはCIやYiiよりも複雑であり、その価値はないようです。
YiiとCodeIgniterは非常に近いものです。 パフォーマンス、ドキュメント、および柔軟性はほぼ同等です。どちらも高速で、十分にドキュメント化されており、十分な柔軟性があります。 CodeIgniterはややシンプルですが、Yiiにはセキュリティ上の利点があります。 最終的な意見をまとめるために、それぞれのアプリケーションのプロトタイプを作成するまで待ちます。
比較テーブルは物事を単純化しすぎるので、私は通常、比較テーブルは好きではありません。 しかし、人々はしばしば短い要約表を見たいと思うので、おおよそのスケッチを提供します：
[1]重要です。 プログラムの作成を開始する前にドキュメントを判断するのは困難です。
[2] CodeIgniterは、XSSフィルタリングと全体的な柔軟性でポイントを獲得します。
元の記事と著作権-ダニエル・カレラ、 「PHPフレームワークの比較-パートI」