PHPに教義を使用する利点は？

Question

ちょうど出会いました 教義 オブジェクトリレーショナルマッパーとDB抽象化レイヤーを備えたプロジェクト。 Doctrineは、他のPHP抽象化レイヤーがしないことを何を提供していますか？また、Doctrine Query Languageで書かれたクエリを介してオブジェクトを取得することとは別に、どのような実用的な使用を行うことができますか？クエリ言語は本当にWebアプリ全体を開発したいものですか？うまく機能しますか？

全体として、教義にアプリを構築することで、維持と理解が容易になりますか？それは過剰に設計されており、小規模サイズのプロジェクトには抽象化層の上に構築されていますか？ （<50 GUI画面）、MySQLを直接操作するのではなく。

Answer 1

Doctrineは、他のPHP抽象化レイヤーがしないことを何を提供していますか？

1. DataMapperパターンを実装しています。
2. サポート 注釈, 、スキーマのXMLおよびYAML。
3. 使用します DQL.
4. PHP 5.3+の利点を使用します。
5. 速く、大きなコミュニティがあります。
6. ORMを除いてODMがあります。

クエリ言語は本当にWebアプリ全体を開発したいものですか？

ビジネスオブジェクトの維持を担当するアプリケーションの一部は、教義の存在を認識する必要があります。そして、その部分は100％の教義ベースである必要はありません。

全体として、教義にアプリを構築することで、維持と理解が容易になりますか？

間違いなく。コードは、読み取り、理解、保守が簡単です。

それは過剰に設計されていますか、それは小規模サイズのプロジェクトにとって賢明ですか？

実際、教義はその基本において非常に単純です。また、小規模、中程度、さらには大規模なアプリケーションにも非常に良い選択です。

---

教義はすべてに対する答えではなく、時には少し問題があることもあります。ただし、典型的なタスクでは非常に便利です。私見この時点でPHPに最適なORM/ODM。

Answer 2

クロジンの答えにいくつかのポイントを追加したいのですが、残念ながらコメントすることはできません。はい、どうぞ：

• Doctrineは、魔法の方法__get（）と__set（）を使用してエンティティの属性にアクセスしないため、すべてのエンティティ属性にはgetter / setterが必要です。これにより、IDEコードの完了が改善され、DBテーブル構造を常に確認する必要はありません。
• 教義は、実際のテーブルフィールド名から完全に抽象化します。エンティティプロパティをDBフィールドにマッピングしたら、どこでもプロパティ名を使用します。テーブル名についても同じです。
• Doctrineは、エンティティの取得の詳細を隠すリポジトリパターンを使用します。
• Doctrineは「Code First」アプローチを利用するため、最初にエンティティを作成してから、データベースを自動的に生成できます。逆ケースも可能です。
• Doctrineには強力なクエリビルダーがあるため、条件付き部品のクエリにビルダーパターンを利用できます。
• Doctrineは、外部のキーと制約を使用して、カスケードアクションを実行し、データを一貫性に保ちます。
• DoctrineのUnitofworkは非常に素晴らしく賢いものであり、他のPHP Ormsには類似点がありません

私見は現時点で、Doctrineが利用可能なすべてのPHP ORMの中で最高のIDEコード完了サポートとDBレイヤーの抽象化を提供しています。それは過剰に設計されておらず、確固たる原則に従います。

Answer 3

Gerkirillの答えにポイントを追加したいと思います。 Magic Getter/Setter Methodのサポートがないことは、私の弱点であり、強さではありません。同一のゲッター/セッターの数十ページをスクロールしたことがある場合は、これらの方法が空間の浪費であることがわかります（コンパイル時間は言うまでもありません）。誰も誤ってオブジェクト変数を設定していないため、セッターはあなたがそれを行うことを妨げません...プロパティを変更したいとき、あなたはセッターを呼び出すだけです（セッターはどのようにプロパティを「保護」しますか？タイプミスを作成し、間違ったプロパティ値を直接設定するために、同じタイプミスを作成して間違ったセッターを呼び出します）。また、セッターやゲッターがプロパティを取得またはセットする以外に何でもすることは非常にまれです。あなたがプロパティを設定したり取得したりするために特別なことをしなければならない場合、そのプロパティは方法でなければなりません（参照 http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html）、またはコードをリファクタリングする必要があります。または、プロパティ検証関数を呼び出す必要があります（通常、オブジェクトが作成された時点）。これは、OOの世界を悩ませている、挑戦されていない真実主義の1つです。標準の受信ウィスダム返信を投稿する前に考えてください。