私は長い間 CodeIgniter を使用してきましたが、最近、より高度な OOP フレームワークに移行する必要性を感じています。Kohana はよく推奨されるオプションのようですが、私の質問は、Kohana と CodeIgniter との違いは何ですか? 相違点、特に構文の相違点のリストは素晴らしいでしょう。
2 に答える
コハナ3.1と、これまでにCodeIgniter2で見た主な利点について説明します。Kohana 3.0の前(1年半前)、私はCodeIgniter、ZF、Symfony、Cakeを使用し、他の多くのことを試しました(現時点では、必要があるという理由だけでYiiを実行しようとしています)。多くの人が「主観的」であると私に唾を吐くのを知っています。どうぞ。
厳格なPHP5.2
Kohanaは、現在のバージョンでは古いコード(2.xまたはCodeIgniterを意味する)を使用していません。完全にオブジェクト指向であり、開発者の邪魔にならないように完全に書き直されました。簡単に言えば、PHP開発の「方法」のように、それを使用して開発するのは自然なことです。
これは、宣伝目的ではなく、「コミュニティによって、コミュニティのために」構築されたフレームワークです。そして、/によってではなく、どのコミュニティにとっても、非常に小さなコミュニティです。
CodeIgniterは、PHP4に長時間ぶら下がっていました。CI2のソースを見ると、PHP5に完全に移行したとは言えません(たとえば、PHP5.1は実際には...PHP 5ではありません)。私はFuelPHPを見てきました。これは、CI2ブランチというよりも、コハナとのCI2のマッシュアップのようですが、確かに可能性があると言わざるを得ません。
HMVC
コハナが自然に感じる主な理由は、このパターンから生まれました。パターンを尊重するためにすべてのリクエストを分離するというアイデアで、RFC 2616を尊重することになりました。これで、リクエストごとに個別のResponseオブジェクトが作成され、コードを非常に適切に再利用できるようになりました。現在、iPhone、Android、およびWebアプリで使用されるWebサービスに取り組んでいます。APIを「内部で」呼び出すことがどのような特権であるかを説明することはできません。生の例:
public function action_delete()
{
$deleted = Request::factory('api/route')
->method(Request::DELETE)
->headers('Accept', 'text/html')
->execute();
$this->response->body($deleted);
}
ハンディキャップなし
コハナの背後にあるチームは、フレームワークを「可能な限り最高のもの」にすることに専念しており、「余暇が多すぎるため、可能な限りすべて」ではありません。各メンテナンスバージョンは、以前のバージョンと下位互換性があり(たとえば、3.1.2と3.1.0)、すべての「メジャー」変更がマイナーバージョンを待機します(たとえば、3.1は「すぐに使用できる」3.0と完全に下位互換性がありません)。以前のマイナーバージョンは、新しいバージョンがリリースされてから6か月間維持されます。
Exten(ding | sions)
Kohanaのカスケードファイルシステムを使用すると、既存のコンポーネント、またはベンダーが使用しているコンポーネントを非常に簡単に拡張できます。インクルード/ロードパスを手動で設定することを考えずに、アプリケーション/モジュールレベルですべてをオーバーライドできます(すべてのファイルとフォルダーが同じ規則を尊重するため)。
ZendFrameworkを含む多数のモジュールがあります。どのようだ?簡単に言えば、ZFやその他のライブラリをKohanaアプリ内のモジュールとして使用することもできます。
コミュニティで構築されたすべてのモジュールに加えて、すべてのKohanaインストールには、ほとんどすべてのアプリケーションが恩恵を受けることができるいくつかが含まれています。
Auth シンプルでありながら、非常に強力な認証ライブラリ。モジュール自体はファイル認証ドライバーのみを提供しますが、ORMを有効にするとより強力なものが得られます。
最も一般的なキャッシュ手法(APC、eAccelerator、ファイル、memcache、SQLite、Wincache、Xcache)用のドライバーを備えたキャッシュキャッシュライブラリ。実装と変更は非常に簡単です(キャッシュドライバーのその後の変更でもワンライナーです)。
Codebench コードのベンチマークが必要な場合、Codebenchは非常に簡単な方法を提供します。
データベース コハナの他のすべてと同様に、データベースモジュールも完全にオブジェクト指向で拡張可能です。MySQLとPDOを完全にサポートしています。
画像 簡単な画像操作のためのシンプルなモジュール
ORM ActiveRecordパターンに基づくデフォルトのORMであり、PHP5マジックメソッドと組み合わせたデータベースモジュールの利点を十分に活用しています。これに加えて、Jelly、Sprig、AutoModeler、またはDoctrineのような他のカスタムPHPライブラリを使用できます。
Unittest Kohanaには、優れたユニットテストモジュールがあらかじめパックされています。これはPHPUnitに基づいており、アプリと完全に「統合」されているため、非常に簡単なTDDが可能です。さらに、フレームワーク全体が単体テストされます。
ユーザーガイドほとんどの開発者は無視していますが、このモジュールは、 Kohanas の最も強力な機能の1つです。APIと残りのKohanaドキュメントを追跡するための最も簡単な方法を提供します。アプリケーションに独自のガイドがないのはなぜですか?あなたもそれについて考える必要はありません!コード内のコメント/規則を追跡している限り、このモジュールが残りの処理を行います。
コード例
規則は非常に似ていますが、コードはCIよりもすっきりしていて、すべてのクラスが自動ロードされます。
更新例(ORMを使用):
public function action_update($post_id)
{
$post = ORM::factory('post', $post_id);
$errors = array();
if ($values = $this->request->post())
{
try
{
$post->values($values)->update();
$this->request->redirect('post');
}
catch (ORM_Validation_Exception $e)
{
$errors += $e->errors();
}
}
$this->template->content = View::factory('post/update', array(
'post' => $post,
'errors'=> $errors,
));
}
この例では、ORMを使用して行を更新し、update()でその値を検証するためにcheck()メソッドを呼び出します。検証が失敗した場合、ORM_Validation_Exceptionがキャッチされ、残りのtryブロックは実行されません(つまり、/ postへのリダイレクト)。最後に、postオブジェクト(Model_Post)とerrors配列の両方がViewに渡され、そこで直接アクセスできます。
すべてのDatabase_Query_BuilderメソッドはORM内で使用できるため、次のような「凝った」操作も実行できることに注意してください。
ORM::factory('post')
->where('user_id','=',$user_id)
->join('users','INNER')
->on('users.id','=','posts.user_id')
->find_all();
または(関係あり):
$user = ORM::factory('user', $id);
foreach ($user->posts->find_all() as $post)
{
foreach ($post->quotes->find_all() as $quote)
{
if ($quote->illegal())
{
$quote->delete();
}
}
}
違法()は、派手な結合などを使用したカスタムモデルレベルのメソッドである可能性があります。このチャンクがいかに非効率的であるかを知っています。これは単なるコード例であり、「追加のクエリよりもJOINの方が優れている」ではありません:)
リンクがあるhttps://stackoverflow.com/questions/717836/kohana-or-codeigniterをご覧ください- http://onwired.com/blog/exploring-kohana-as-an-alternative-to-codeigniter/ - このまったく同じ質問のほとんどに答えました。