Doctrine 2またはPropel 1.5 / 1.6を選択する必要があります。なぜですか？
Doctrine 2（またはそれ以降）およびPropel 1.5（またはそれ以降）を使用したことのある方からお聞きします。これらの2つのオブジェクトリレーショナルマッパー間のほとんどの比較は、古いバージョンに基づいています-= Doctrine 1対Propel 1.3/1.4、および両方のORMは、最近のリビジョンで大幅な再設計を行いました。たとえば、Propelの批判のほとんどは、「ModelNamePeer "クラス。いずれの場合も1.5では非推奨です。
これが私がこれまでに蓄積したものです（そして、私はこのリストを可能な限りバランスをとるように試みました...）：
- 推進、動かす
- 長所
- 非常にIDE友好的、実際のコードが生成されるため、PHPマジックメソッドに依存しません。つまり、IDE コード補完 は実際に役立ちます。
- 高速（データベースの使用に関しては、データベースでランタイムイントロスペクションは行われません）
- スキーマバージョン間のクリーンな移行（少なくとも1.6ベータ版）
- PHP 5.3モデル（つまり名前空間）を生成できます
useXxxメソッドなどを使用して、多くのことを単一のデータベースクエリに簡単にチェーンできます。 （上記の「コード補完」ビデオをご覧ください）
- 短所
- 追加のビルドステップ、つまりモデルクラスのビルドが必要です。
- 生成されたコードは、Propelのバージョンが変更されたとき、設定が変更されたとき、またはスキーマが変更されたときはいつでも再構築する必要があります。
これは直感的でない場合があり、モデルに適用されたカスタムメソッドが失われます。 （おもう？）- 違います;生成されたクラスは基本クラスであるため、カスタムメソッドは失われません。 Propelは拡張のためのエンティティクラスを提供します。 - 一部の便利な機能（バージョンの動作、スキーマの移行など）はベータ版です。
- 長所
- 教義
- 長所
- もっと人気
- Doctrineクエリ言語は、PropelのActiveRecord戦略で簡単に可能であるよりも、データ間の潜在的に複雑な関係を表現できます。
- Propelと比較すると、再利用可能なビヘイビアーを追加するのが簡単です。
- スキーマを構築するためのDocBlockベースのコメントは、個別のXMLファイルではなく、実際のPHPに埋め込まれています。
- PHP 5.3名前空間をどこでも使用する
- 短所
- まったく新しいプログラミング言語（Doctrine Query Language）の学習が必要
- いくつかの場所で「魔法の方法」の観点から実装され、IDEオートコンプリートの価値がなくなりました。
- データベースのイントロスペクションが必要であるため、デフォルトではPropelよりも少し遅いです。キャッシングはこれを取り除くことができますが、キャッシングはかなり複雑になります。
- コアコードベースに含まれる動作が少なくなります。 Propelが箱から出して提供するいくつかの機能（入れ子になったセットなど）は拡張を通してのみ利用可能です。
- Freakin 'HUGE :)
- 長所
これは、両方のツールで利用可能なドキュメントを読んだだけで収集されました。実際にはまだ何も構築していません。
ただし、両方のツールを使用したことがある方、各ライブラリの長所/短所についての経験、および現時点での推奨事項についてお話ししたいと思います。
現在の傾向に反して、Doctrineを推奨していますが、別の言い方をする必要があります。また、私の個人的な好みは私の個人的な経験を重視していますが、@ Danによると、どちらも非常に強力です。
私はDoctrineが好きではありません。サイズや魔法のメソッド全体がディールブレーカーそれで、私は Propel を使用します、なぜですか？主にそれがシンプルであるため、そしてソフトウェア開発におけるシンプルがgoodであるためです。個人的には、デザインに貪欲になるのは悪いことだと信じています。
Propelを使用して、自分のシステムに repository pattern 実装を実装することができました。これは、ORMの中で最も高速なものの1つであるPropelのパフォーマンスは言うまでもなく、非常にうまく機能します。 。
したがって、私の基本的な答えは Propel です。これは、少ないコードで優れたソフトウェアを実現し、IDEデータベースに接続してそれを実行しているORMソフトウェアのポイントを失うことなく、優れたインテリセンスを提供するために...
お役に立てれば幸いです
Doctrine 2に関する情報が間違っています...
- DQLはほとんどSQLなので、学ぶことはあまりありません。
- Doctrine 2は「マジック」を使用しません（最新のPHPライブラリで期待されるもののみ）。
- Doctrine 2は積極的にデータベースのイントロスペクションを行いません...マッピングはあなたのエンティティ/マッピングファイルに保存され、あなたのデータベースがそれに適合すると仮定します。
- キャッシングは「かなり複雑」ではありません。
- Doctrine 2には、すぐに使える「振る舞い」はありません
私は以前にPropelを使用したことがありませんが、Doctrine 2ははるかに新しく、本当に高品質のコードベースを持っています。しかし、PropelはActive Recordを使用しているようですDoctrine 2はData Mapperパターンを使用します。
Doctrine 2が新しいという欠点は、サードパーティの例がないことですが、急速に増えています。
Doctrine 2 ...をお勧めします.
コメントから、PropelまたはDoctrineを選択して、レガシーアプリケーションのORMの必要性を置き換えたり、満たしたりしようとしているようです。
そうは言っても、どちらかに移行することでアプリケーションが大幅に改善されるという事実を見失わないことが重要だと思います。だから、本当の間違った答えはありません。
したがって、選択するソリューションは、主に次の質問に対する答えに基づいて、好みに応じて異なります。
- 現在のソリューションに統合するのに最適なものはどれですか。
- どちらのAPIを好みますか？
- どちらに貢献したいですか？ （パッチ、ドキュメント、バグレポートなど...）
個人的に、私はDoctrine 2をお勧めします。コミュニティ、ドキュメント、およびアーキテクチャのためです。
統合性が高く、高速で、強力なので、Propelをお勧めします。コードを生成することは、実行時にクラスをロードすることよりも優れており、デバッグ手順を容易にし、作成したものを表示します。したがって、ビルドステップは問題ではありません。
Doctrine2には公式の振る舞いはなく、DataMapperのデザインパターンはクールですが実際の生活では使いにくいです。ああ、DQLは面倒ですが、国境を越えた学習言語です...
オブジェクト（DQL/SQL /何でもない）で考えたい場合は、Propelを選択します。
Doctrine2はSymfony2デファクトの一部ですが、物事はすぐに動きます。最後のFabien Potencierの記事をご覧ください。
乾杯、ウィリアム
どちらもとても良いです。いくつかのEdgeのケースには、他のケースよりも何かをしたり、何かをしたりできるものがあります。私がどちらかで問題を経験したことがあったとしても、それは彼らができないことよりも私の知識の欠如によるものでした。
これは、ドキュメントの作成とサポートが、コードの本質的な能力よりも重要であることを意味します。あなたが問題に遭遇したときにあなたを助けることができる誰かを知っていますか？ドキュメンテーションはどの程度うまくいきますか？それらの1つは、あなたにとってより自然に「自然に」感じますか？
私は、大規模なレガシーmysqlアプリケーション（200テーブル程度）にPropel 1.63を選択しました-ここに含まれる要因：IDEサポートにより、コード開発者がコード補完で簡単に自分の道を見つけることができます;データベーススキーマのサポート、パフォーマンス、列挙型のより良いネイティブサポートといくつかの動作の使用。実際には、Doctrineから始めました。これはSymfony2によってサポートされる最高の方法でしたが、PropelがSymfony（次のプラットフォーム私は最終的に移行します）上記の問題の処理が改善されたために切り替えました。後悔はまったくありませんPropelは決定的な勝者です。