ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    CodeIgniter vs. CakePHP

    このエントリーを含むはてなブックマーク はてなブックマーク - CodeIgniter vs. CakePHP あとで読む
    PHPフレームワークの比較記事がありました。
    メモとして翻訳してみます。

    原文
    CodeIgniter vs. CakePHP

    翻訳文(Google翻訳)
    CodeIgniter 対 CakePHP

    実践マスターPHP+MySQL―PHP4/PHP5対応
    小島 まさご
    ソーテック社
    2007-06-18
    2604円


    CodeIgniterCakePHP

    2007年3月18日

    私は、必ず熱狂者(否定的な意味の言葉)を突然に呼び込んでしまうため、この種の投稿をまとめることを恐れています。
    まずちょっと言わせてもらうと、私が自分の好みをさしはさむ時でも、私は公平であろうと努力して、評価において正直であり、事実を保とうとしました。

    私はこの2つのフレームワークを互いに挑ませていますが、実際に明白な勝者はいません。
    各々に強みと弱みがあり、特定の特徴があなたの好みとして落ち着くでしょう。

    なぜこの2つを比較するのか?

    CakePHPCodeIgniterは、PHP4のサポートを含め、いくつかの点でアプローチがかなり類似しています。
    従って、一方に言及することは、他方に言及していることなります。

    それらの両方は、ビュー(ユーザーが見るもの)をコントローラ(データをビューに与えるために、モデルから引き出す)経由の(データ)モデルから分離させる、というMVC構造を作ろうしています。

    両方とも、URLを受け取るルーティングを使って、コントローラの中で特定の機能(CakePHPではアクションと呼びます)に対応させます。

    CodeIgniterはルーティングに対して正規表現をサポートしていますが、あなたはこの特徴をCakePHP1.2まで待たねばなりません。
    訂正:CakePHP 1.1がルーティングのために正規表現をサポートしていますが、マニュアルで詳述されておらず、1.2で更新されています。

    (意訳はここまで)



    それらの両方がモデルに基づく視点を発生させる自動化された方法であるScaffoldingを支持します。 足場は簡単なプロトタイピングのために意味されます、そして、CodeIgniterは、より遠くにURLのキーワードが足場にアクセスするのさえ必要であることによってそれを前進させます。 この特徴を本質的には任意の状態でおいて、私は、1つがキーワードを省略するかもしれないと推測しています。 私は、私が時々人目のために意図されなかった個人的なプロジェクトを築き上げるときキーワードを使用する必要はないのを好みます、そして、キーワードを使用するのは、迷惑でしょう。

    そして、リストは続きます...

    簡易性へのアプローチ

    私は、CodeIgniterの訴えの多くがそのアプローチのその単純さであると思っています。大部分の仕事はコントローラでされます。そして、図書館でロードして、モデルからデータを得て、見解を引き入れます。すべては明白な視界にあります、そして、あなたはものがどのように働くかについて、本当に見ることができます。

    CakePHPの単純さは、オートメーション(婉曲的に、「automagicな」ものと称します)を通して来ます。それは、コーディングプロセスをより速いが、あなたの頭を芯に入れることなく「続いていること」を見つけ出すのがより難しくします。私のために、私はすべてがどのように働くか理解したいです、そして、私は一度ならずフードの下で引っかき回さなければなりませんでした。ちょうど始まっている人々のために、ものは多分少し気が重く見えるでしょう。

    モデルの動作

    CodeIgniterのモデル処理は、かなり簡単であり、基本的にこれらの例のような少数の簡単な命令で標準的なSQL問い合わせを模倣することができます:

    $query = $this->db->getwhere('mytable', array(id => $id), $limit, $offset);

    $this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);
    $query = $this->db->get();



    注: この例の第2部分で鎖でつなぐ方法はPHP5だけで利用できる。

    また、モデルオブジェクトを作成することができて、それを中にロードして、注文の仕事を取り扱うために、カスタムメソッドを作ることができる。
    あなたは、コードをMVCサイロに隔離するのを助けるために、コントローラではなく、モデルの中でこれをしたがっているでしょう。



    CakePHPは現在のコントローラーに一致させるモデルの自動的に負荷によってわずかに別のルートを取る(コントローラーはモデルにと関連付けられる)同様に示されがちである。 この自動化されたローディングを消し、コントローラーによって代りに荷を積まれるべきである異なったモデルを割り当てることができる。

    CakePHPはまたあなたのためのすべてのモデル連合の確立によって事を更に取り、実際に容易なただすことを可能にする。 例えば、仮定して私はpost_controllerと示されるコントローラーに私次をすることができるある:

    $this->Post->Comment->findAllByPostId ($id)私は2つの概念を示すのでこの特定の問い合わせを選んだ。 第1私がポストモデル(私はポストモデルのその連合を定義した仮定する)によってコメントモデルにアクセスしてもいいという事実である。 第2は私がfindAllByPostIdと呼ばれる方法を有するという事実である。 CakePHPは記録がxがあなたが見つけることを試みているフィールド名と等しいfindByXおよびfindAllByXの問い合わせによってつかまれるようにする。

    私がケーキの輝やきを考える一方、あるすべての準データを自動的に引込む機能に。 例として次の問い合わせを取りなさい:

    $this->Post->findById ($id)この問い合わせは自動的にこのポストによって関連付けられたすべてのコメントを引込む。 実際に便利な原料。

    確認
    モデルを使用した場合、当然データ確認を扱わなければならない。 CodeIgniterのデータ確認は確認のクラスによって扱われる。 一組の規則は確認の目的に定義され、割り当てられて得る。 確認の目的は自動的に(私は仮定する) URLか形態によって渡されるデータを認可する。 そこにから、それが扱われていかに得るか決定できる。 確認のクラスはまた特定の分野のためのエラーメッセージを置くプロセスのいくつかの自動化を助けることができる。

    CakePHPはモデルを通して2つの方法の1つの確認自体を扱う。 第1モデルで宣言される認可の変数で定義される各分野に対して単一テストを使用する。 これは簡単な原料のために良く働くが、それはすぐにcumbranceになる。 簡単な確認を越えて、私はbeforeSaveの失敗する分野を無効にする注文の確認を行うのに製品回収を利用する。

    それは私のため1つが「」勝つかどれにに関してトスである。 CakePHP 1.2により多くの柔軟性を可能にするために確認システムが改めたビットをある。

    眺め
    CakePHPは(あなたが使用によってこれをランタイムに容易に転換できる)デフォルトのレイアウトかなりよく扱う。 レイアウトは2つの変数をデフォルトでもらう: title_for_layoutおよびcontent_for_layout。 各行為は場所にスパッツを入れる特定の眺めに自動的につながる。 再度、それは「automagic」アプローチである。 あなたのファイルを特定の方法と示す限り、コントローラーは自動的にモデルおよび意見につながれて得る。 これすべてを、余りに打ち消すことは、十分に容易あなた自身のレイアウトを定義するか、またはファイルを見る。 しかし特注の貯蔵のメカニズムを実行すること困難にさせる発生させた眺めデータを得る便利な方法がない。

    CodeIgniterは非常に簡単なアプローチを取る: のようにファイルを、ほとんど含みなさい。 各ファイルは荷を積まれ、処理されて得る。 templatingクラスがあるが、作り付けの眺めの処理を越える事を大いに簡単にしない。 常にによってヘッダーおよびフッター呼出しを含むCakePHPのアプローチをまねることができるが、継ぎ目が無いようにない。 CodeIgniterの提供のホック眺めを許可し、注文システムと打ち消され、取り替えられるメカニズムを貯蔵する。

    箱の特徴から
    私の心のCodeIgniterはftp、電子メール、XMLRPCアップロードする、ファイルジッパーの符号化および多くのためのクラスとこれに渡す勝つ。

    裏面きれいなライト試みのCakePHPはパン屋を使用してそれを補う来る。 あなたが必要とするかもしれないあらゆる特徴のための第三者のクラスで、CodeIgniterのように、容易に落ちることができる。 私がそれを試みなかったが興味深く、問題なしでCakePHPにCIのクラスの多数でおそらく落ちることができる。

    自動起動
    CakePHPは適用広い変更が他のコントローラーがすべて受継ぐ基礎適用コントローラーによってされることができるように可能にする。 同様に、適用モデルファイルを使用して全体的なモデル方法を作成できる。 但し、コントローラーレベルの製品回収(beforeFilter、afterFilterおよびbeforeRender)の何れかを使用してコントローラーのレベルで事を微調整できる。 自動起動助手および部品のような事はまた個々のコントローラーのレベルで容易に指定することができる。

    CodeIgniterは助手、図書館および差込の自動起動を可能にするが、この適用広いする。

    ドキュメンテーション
    ドキュメンテーションはその中で成長するには十分のフレームワーク井戸の理解に主である。

    CodeIgniterに中文書化される各方法および特性が付いている全部品の完全なリストがある。 CIにまた多くのユーザー堤出されたコードを特色にするwikiおよびフォーラムがある。

    CakePHPは、一方では、また組織されない。 マニュアルは大いに行くあるセクション実際に示しapiが提供するものをを越えてとの年齢を始めている。 元のドキュメンテーションのフォーマットのために、またCHMおよびpdfのような他のフォーマットのそれを得ることができる。 CakePHPにユーザー堤出された記事、部品、等を含んでいるパン屋がある。 devのチームはまたircチャネル(irc.freenode.netの#cakephp)で重く時を過ごす。 最終的に、かなり活発のCakePHP Googleのグループがある。

    最終的な評決
    私はかなり実用的な個々であり、この2つのフレームワークにそれらのためにたくさん行くことがあることに正直に感じる。 それらはアプリケーション開発にSymfonyのような何かである複雑さより大いに簡単なアプローチを取る。

    私は今でも「automagic」そのの多くのための終わるCodeIgniterが私述べたCakePHPの個人的にファンである。 そしてそれは各々の新しい繰り返しとずっと欠点得ている演説したである(1.2は1.1上のかなりの跳躍であるが、解放した前に)しばらくまだある。

    ノート
    この比較はCodeIgniter 1.5.2に関するドキュメンテーションに基づき、CakePHP 1.1を使用された。 私はそのような事を設計し、開発し、テストするために必要な時間のためにとりわけ性能の主題を避けた。
    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/93-549c574b

    FC2Ad