Symfonyとcakephpの違いは概念的には何ですか?
このスレッドのバランスをとるために、これがsymfonyが好きな理由です:
概念的には、違いは次のとおりです。
私ができる最善のアドバイスは、両方で独自のシンプルなデータモデルをすばやくセットアップし、いくつかの基本的なインターフェイスを試し、自分のコーディングスタイルに最適なものを確認することです。どちらのフレームワークにも非常に活発で情熱的なユーザーコミュニティがあり、どちらにしても決定を後悔することはないと思います。
大きな違いは、モデルの作成方法にあります。CakePHPモデルはPHPで作成され、SymphonyモデルはYAMLで作成され、Propelを使用しています。 CakePHPのアプローチは、RORのActiveRecordに似ています(ただし、AR実装ではありません)。一般に、CakePHPはRails風です。
私の意見では、CakePHPのドキュメントとツールはより幅広い対象読者をもち、構文とヘルパーは簡単ですが、PHP5を排他的なターゲットとしてまだ受け入れていません(オートロードは実際にはありません)。一般に、CakePHPのアプローチは確立された標準に従うため、CakePHPのアプローチを好みます。また、その組織を称賛します。 Kohana をお勧めします。PHP5の良さです。
この質問に関するスタックオーバーフローには 別の投稿 がありますが、焦点が少し異なります。
編集:Symfonyを見直して、「いいえ」と言った理由を見つけて、これらを思いつきました—意見やマイレージは異なる場合があります:
CakePHPはまた、完全にシンプルな足場とわかりやすいCLIツールを提供します。 SymphonyのCLI構文は少し気味が悪く、Symfonyの「CRUD」は同じではありません。それをSymfonyの(awkard)アクション構文と組み合わせて、Symfonyの貧弱に設計された(そして理解しにくい)Webサイト、およびサードパーティの有料ドキュメント(Amazonの本)の好みを投入すると、短所の列に多くのダニがあります。
上記のCakePHPと制限に関する主張のいくつかは、単に真実ではありません。クエリは可能です。あなたはそれを作る方法を知っている必要があります。 CakePHPの「オートマジック」はすてきですので、高速で実行できます。それは、開発にとって最速のフレームワークです(そのため、RoRに非常に密接にモデル化されているため、明らかに大きな成功と話題となっています)。データを異なる方法で取得し、いくつかの短いメソッド呼び出しと配列パラメーターを指定して、より複雑なクエリを実行する、より高度な動作があります。
しかしながら。私が知る限り、他のフレームワークには「自動マジック」メソッドとクラスがありません。 Cakeは最も一般的なタスクを取り、それを簡単に行う方法を提供します。本当に賢いのであれば、ほとんどのコーディングをモデルレベルで行い、app_modelおよびapp_controllerファイルを利用して、非常に効率的なアプリケーションを作成します。
コンソールは素晴らしく、常に拡大しています。コミュニティは本当に驚くべきものであり、より速く物事を進めるのに役立つ多くの貢献があります。必要なもののほとんどが利用可能であるため、文字通り設計してから「ピース」を所定の場所に移動して、非常に迅速にアプリを構築できます。他のフレームワークでは取得できません。通常、コーディングに多くの時間を費やす必要があります。
最後に。ドキュメントは遅れていましたが、今でははるかに良くなっていますし、Cakeもこのドキュメントの欠如とバージョン1.1の期間中に厳しいレビューを受けました... 1.2で、Cake2とCake3が水平線上にあります...あなたは多くの意見が変わるのを見るでしょう。
1.1以降、CakePHPを使用しています。私はそれを固く信じています。巨大な企業サイトで使用しました。 1日あたり数百万件のヒットを受け取ります... WordPress and Drupalソリューションの場合。同様に、SymfonyとCodeIgniterがスケーリングを支援します。これらのフレームワークのいずれについても悪いことは言えません。 CakePHPでコーディングに費やす時間を減らし、より大きなコミュニティ(および非常に友好的なIRCチャネル)を見つけます。
CakePHPに関する上記のコメントに対する私の回答の一部と、(場合によっては)認識されている障害の一部について説明します。
大きなWebサイトは、CakePHPを使用して実行されます。Mozillaアドオン、MITによるスクラッチ、Hot Scriptなどがあります。 CakePHP Webサイトの一番下に、より大きなリストがあります( http://cakephp.org )。とにかく、フレームワークが完全に愚かでない限り(CakePHPは愚かなことではありません:D)、優れた開発者はフレームワークを使用してスケーラブルなWebサイトを構築できるはずです。
フレームワークのすべての機能を説明する非常に優れた(無料の)CakePHPチュートリアルはありませんが、ドキュメントは非常によくレイアウトされており、冗長です。明確でないものはすべて、GoogleグループおよびIRCで解決できます。ドキュメントに対するすべての変更/修正を歓迎します。多くのことがアプリケーション固有であり、人々が興味深いヒントやコツを思い付くので、ドキュメンテーションは開発者の中核の問題ではありません。したがって、誰もがコメントするだけではありません。もちろん、それはすべてモデレートされているため、ほとんどのクラフ/スパムは追加されません。
コードはモジュール式であり、コア機能に取って代わる新しいコードを追加できます。コードの多くは単純にPHPクラスです。このような機能を記述するのは負担になる可能性があり、別のクラスをfillinsとして使用しようとしませんでした。はい、他のORMを処理しません、したがって、デフォルトのままではありませんが、これはCake3で修正する必要があります。これにより、他のPHPクラス(PropelとDoctrineサポート)。
CLIは非常に優れており、アプリケーション固有のサポート用に拡張するのは簡単です。 1つの例は、githubからインデックスを作成した他のCakePHPプラグインを自動的にインストールするシェルプラグインを最近開発したことです。非常に使いやすく柔軟なものを構築するのに約5時間かかりました。私はそのような機能がSymfonyに存在し、RoRにも存在すると確信しています:)
Railsに似ているということは、そうでもありません。多くのものは似ており、結局MVCフレームワークであり、CakePHPは「コンベンションvs構成」アプローチを採用しています。 PHP4は、PHP5のみのサポートのためにSymfonyが持っている疑いのない、より良い構文のmucksをサポートしますが、それでも非常に使いやすく直感的です。フレームワークは、そのままのクローンではないため、すぐに使用できるRailsのすべての機能を提供しません。CakePHPはライブラリではなくフレームワークです(こんにちはZend)。箱から出してすぐにすべて。
ビューの生成は、CakePHPでは少し不安定です。 CakePHP 1.3および2.0で大幅に強化されています。これは、すべてのモデル、ビュー、コントローラーのカスタムテンプレートをサポートします(現在のタイプのビューとは対照的です)。また、必要なものを正確に作成するためにカスタムテンプレートと組み合わせて使用できる特定の種類のビュー(管理者ビューのみを含む)のみを自動でベイクするニールクルークのユーザーによるgithub上のシェルタスクのセットが存在します。 CSSスタイリングも役立ちます:)しかし、これは間違いなく改善できるものです。
CakePHPは、Model :: findメソッドでさまざまなパラメータを取りますが、特定の場合には生のSQLクエリを使用すると便利な場合があります。 Model :: find()メソッドは非常に柔軟で、複雑な検索結果を作成する限り私を失敗させませんでした。これはORMに慣れていることに関係していると思いますが、これには必然的に時間がかかります。
データベースに関連するアクションが実行される場所であるため、フォームの検証は論理的にモデル層で行われる必要があります。私が信じる特定のビューで代替検証を指定するか、検証を交換することができます(これには動作がありますが、それなしではそうするのは難しくありません).
多次元配列は少しばかげていますが、おそらく多次元オブジェクトを持っているでしょう。 PHP4にはオブジェクトモデルが壊れていたため、CakePHPはオブジェクトを使用しません。これはCakePHPの将来のバージョンで修正されています(前のコメントで上で指摘したように)が、場合によってはPHP4をサポートするフレームワークがあると便利です。繰り返しますが、YMMVと私は、アプリケーションの速度と開発の速度の両方で、PHP5全体が大きな恩恵になることに同意します。
データベースは自由に交換できます。 CakePHPは、DBの1つのタイプのみに固有の機能を許可しません(したがって、MySQLのみにあるENUMのサポートが削除されたため)、ORMは常にサポートされ、常に有効なクエリを構築できます。必要に応じて、モデルごとに1つずつ、複数のデータベースをアプリケーションに含めることができ、それらを自由に交換したり、特定のモデルに対してデータベースをまったく使用しないことさえできます。いいえ、特定のデータベースに関連付けられていません。
最終的に、あなたの選択はあなた次第です。両方を調べてドキュメントを読み、グループ、IRCチャンネル、ブログ、両方のフォーラム、両方のフレームワークを確認してください。読者が用心してください、私はCakePHPの開発者なので、私の投稿にはバイアスがあります。
既存の回答に加えて、可能であれば両方を試してください。私は両方ともかなり使いますが、しばらくして、symfonyを好むようになりました。
しかし、それはどちらかが優れているからではなく、symfonyが私の心の動作方法に合っているため、フレームワークの外でソフトウェアを書くときの動作に近いため、より直感的に感じるとかなり確信しています。他の人が自分の心が別のフレームワークのパラダイムに適合すると思うかもしれないと期待しています。
そうは言っても、オブジェクトではなく配列を使用することで、cakephpのオブジェクトは弱点だと思います。 (これは、難しいことをする必要があるたびに、定期的に私の内部で激しい憎悪に発展するものです...!)彼らはまったく同じことをすることができますが、データを表すために配列ではなくオブジェクトを返します。既存のモデルクラスに関数を記述して配列を渡すのではなく、データオブジェクトに追加の機能を追加して、目的を達成することができます。
さらに1つの違いは次のとおりです。Symfonyは3つの環境に分かれています:開発、生産、テスト-CakePHPはできません!製品の開発とテストは同時に簡単です
CakePHPのモデル層は混乱です。カテゴリとアイテムオブジェクト間の多対多のリレーションシップなどの簡単な操作を行ってから、特定のプロパティセットを持つカテゴリ内のすべてのアイテムを取得してください。
お気に入り:
SELECT items.* FROM items, categories, item_categories WHERE item.available=1 AND category.id=1 AND item_categories.category_id = category.id
モデルのfind()メソッドを使用した1つのステートメントでは、それほど些細なことは不可能です。
また、コアAPIには、上記のitem_categoryテーブルに1つのアイテムのように単一の多対多の関係を追加する方法はありません。誰かがベーカリーに投稿した行動を含むオンラインのソリューションがいくつかあります( http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior )が、それはただのものですPropel、Torque(Java)、Hibernate(Java)、SQLObject(Python)、SQLAlchemy(Python)などの優れたORMフレームワークはすぐにサポートされます。基本的に、不足している機能を追加するためにPHPコードをたくさん書くか、生のSQLクエリを使用する必要がありますが、フレームワークの主な目的は、あなたが書いているアプリケーションに集中できるので、CakePHPで本当に多くを得ることはありません。
他にも多くの問題があり、それらはすべて、モデルレイヤーに関連付けられているフォーム検証、乱雑な多次元配列の処理、生のSQLの使用、特定のデータベースへのアプリの関連付けなど、モデルレイヤーに実際に関係しています。
Symfonyを使用すると言います。大きなフレームワークは習得するのに数日かかるかもしれませんが、それだけの価値があるでしょう。私が取り組んでいるプロジェクトにCakePHPを使用するつもりでした。symfonyに切り替えたこれらのタイプの問題が多すぎたので、順調に進んでいます。
Cake 2.0は、必要なクラスのほとんどをうまく自動ロードしますが、Symfony 2では、すべてのクラスがスクリプトの先頭に多数のインポートを持たなければならないことがわかりました。これらすべてのインポートを記憶しようとすることはnear-impossibleなので、常に便利なリファレンスが必要です。
例 Symfony 2コントローラーコード...
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
// bunch of other imports accumulate here...
class HelloController {
...
ああ、うん。それは良いかもしれませんがOO純粋主義者のためのテクニック、それは開発時間を延ばします(by RAD))。