Doctrine 2またはPropel 1.5 / 1.6を選択する必要がありますか？[閉まっている]

Doctrine 2（またはそれ以降）およびPropel 1.5（またはそれ以降）を使用したことがある人からの話を聞きたいです。これら2つのオブジェクトリレーショナルマッパーのほとんどの比較は古いバージョン（Doctrine 1とPropel 1.3 / 1.4に基づいています）に基づいており、両方のORMは最近のリビジョンで大幅に再設計されました。たとえば、Propelの批判のほとんどは「ModelName Peer」クラスにしているようです。これらのクラスはいずれの場合も1.5で廃止されます。

ここに私がこれまでに蓄積したものがあります（そして、私はこのリストをできるだけバランスの取れたものにしようとしました...）：

• 推進
  • 長所
    • PHPのマジックメソッドに依存するのではなく、実際のコードが生成されるため、IDEに非常に優しい。これは、コード補完などのIDE機能を意味しますなどのが実際に役立つます。
    • 高速（データベースの使用に関しては、データベースでランタイムのイントロスペクションは行われません）
    • スキーマバージョン間のクリーンな移行（少なくとも1.6ベータ）
    • PHP 5.3モデル（名前空間）を生成できます
    • useXxxメソッドのようなものを使用して、多くのことを単一のデータベースクエリに簡単に連結できます。（上記の「コード補完」ビデオを参照）
  • 短所
    • 追加のビルドステップ、つまりモデルクラスのビルドが必要です。
    • 生成されたコードは、Propelのバージョンが変更されたり、設定が変更されたり、スキーマが変更されるたびに再構築する必要があります。これは一部には直観的ではなく、モデルに適用されたカスタムメソッドは失われます。（おもう？） -真実ではない; 生成されたクラスは基本クラスであるため、カスタムメソッドは失われません。Propelは拡張専用のエンティティクラスを提供します。
    • いくつかの便利な機能（バージョンの動作、スキーマの移行など）はベータ版です。
• 教義
  • 長所
    • もっと人気
    • Doctrine Query Languageは、PropelのActiveRecord戦略で簡単に可能なものよりも潜在的に複雑なデータ間の関係を表現できます。
    • Propelと比較した場合、再利用可能な動作を追加するのが簡単です。
    • スキーマを構築するためのDocBlockベースのコメントは、個別のXMLファイルではなく、実際のP​​HPに埋め込まれます。
    • どこでもPHP 5.3名前空間を使用します
  • 短所
    • まったく新しいプログラミング言語（Doctrine Query Language）を学ぶ必要があります
    • いくつかの場所で「マジックメソッド」の観点から実装されており、IDEのオートコンプリートは価値がありません。
    • データベースのイントロスペクションが必要なため、デフォルトではPropelよりもわずかに遅くなります。キャッシングはこれを削除できますが、キャッシングはかなり複雑になります。
    • コアコードベースに含まれる動作が少なくなります。Propelが提供するいくつかの機能（ネストされたセットなど）は、拡張機能を介してのみ使用できます。
    • Freakin 'HUGE :)

これは、両方のツールで利用可能なドキュメントを読むことによってのみ収集しましたが、実際にはまだ何も作成していません。

ただし、両方のツールを使用して、各ライブラリの長所/短所に関する経験を共有し、この時点での推奨事項を共有している人からの意見を聞きたいと思います。

Doctrineを推奨する現在の傾向に反対します。また、私の個人的な好みは私の個人的な経験に基づいていますが、@ Danが言ったように、それらは両方とも非常に強力です。

私はあなたがサイズとしているブツ全体魔法の方法のように、前に述べた理由のいくつかのための教義好きではない契約ブレーカを私と一緒に。だから、私はPropelを使用します、なぜですか？主に、それは単純さであり、ソフトウェア開発の単純さは良いからです。私の個人的な考えでは、デザインに貪欲になることは悪いことです。

Propelを使用して、自分のシステムにリポジトリパターンの実装を実装することができました。これは、Propelのパフォーマンスは言うまでもなく、私が見た中で最も速いORMの1つです。

だから、私の基本的な答えはPropelです、なぜならそれはより少ないコードで良いソフトウェアを達成するからですし、それがデータベースに接続し、それ素敵をやっているORMソフトウェアのポイントを失うことなく、良好なインテリセンスを提供するためにIDEを支援し...

私が助けてくれることを願っています

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のニーズを置き換えるか満たそうとしているようです。

そうは言っても、どちらかに移行することでアプリケーションが大幅に改善される可能性があるという事実を見失わないことが重要だと思います。だから、本当の間違った答えはありません。

したがって、選択するソリューションは、主に次の質問への回答に基づいた好み次第です。

1. 現在のソリューションに最適なのはどれですか？
2. どのAPIを好みますか？
3. どちらに貢献しますか？（パッチ、ドキュメント、バグレポートなど）

個人的には、Doctrine 2はコミュニティ、ドキュメント、アーキテクチャのため推奨します。

Propelは、統合性が高く、高速で、強力であるため、お勧めします。コードを生成することは、実行時にクラスをロードすることよりも優れており、デバッグ手順を容易にし、作成したものを示します。したがって、ビルド手順は問題ではありません。

Doctrine2には公式の振る舞いはありません。DataMapperのデザインパターンはクールですが、実生活では使いにくいです。ああ、DQLは苦痛ですが、学ぶべき境界言語です...

オブジェクト（DQL / SQLなしなど）で考えたい場合は、Propelを選択してください。

Doctrine2は事実上のSymfony2の一部ですが、物事はすぐに動くでしょう、最後のFabien Potencierの記事を見てください。

乾杯、ウィリアム

両方ともとても良いです。他の人よりも何かをしたり、より良いことをしたりできるエッジケースがいくつかあります。私がどちらかで問題を経験したところはどこでも、彼らができないことよりも知識の不足によるものでした。

これは、コードの本質的な能力よりもドキュメントとサポートが重要であることを意味します。問題が発生したときにあなたを助けることができる人を知っていますか？ドキュメントをどれだけうまく活用していますか？それらの1つは、あなたにとってより自然に「感じ」ますか？

大規模なレガシーmysqlアプリケーション（200テーブル程度）にPropel 1.63を選択しました-ここに含まれる要因：新規開発者がコード補完で簡単に道を見つけられるようにするIDEサポート。クロスデータベーススキーマのサポート、パフォーマンス。列挙型のネイティブサポートの改善といくつかの動作の使用。実際、これはSymfony2で最もよくサポートされていたためDoctrineから始めましたが、PropelがSymfony（最終的に移行する次のプラットフォーム）でサポートを大幅に改善すると、上記の問題の処理が改善されたため切り替えました。Propelが後悔することは決定的な勝者ではありません。