最高のMVC、Doctrine2、Datamapper Practiceは何ですか？

Question

Zend FrameworkセットアップでDoctrine2を使用することを検討しています。主にデータベースでドメインモデルを分離するため、データマッパーパターンが本当に好きです。

私の質問は、私のコントローラーで教義とDQLを使用するためのベストプラクティスは何ですか？

1. コントローラーは、Doctrine DQL/EntityManagerを直接使用して、ドメインモデルを保存/ロードしますか？

2. ドメインモデルを保存/ロードするためのデータマッパーパターンに独自のクラスを作成し、自分のクラスでDoctrineを内部で使用しますか？

プロ。もちろん、＃1は独自のデータマッパーモデルを作成する必要はありませんが、＃2では、後で教義を置き換えることができます（理論的に）

あなたならどうしますか？

Answer 1

あなたの抽象化の質問に関して、それは本当にこのプロジェクトの寿命と、あなたのコードがどれほどポータブルであるかに依存すると思います。最小限のメンテナンスが必要な1回限りのWebサイトである場合、追加の抽象化レイヤーを放棄し、コントローラーにDoctrineコードを書くだけの時間を節約するでしょう。ただし、このコードを再利用したり、異なるプラットフォームに移動したり、長期間維持することを計画している場合は、その抽象化を追加するために時間をかけて追加します。

まだフレームワークを調査している場合は、 コハナ. 。それは基本的に、PHP5用に書かれたCodeigniterの軽量の書き直しです。

Answer 2

PIX0Rからのアドバイスを2番目に。追加の抽象化は、潜在的に長い寿命があり、おそらく多くの開発者がいるより大きなプロジェクトである場合にのみ価値があります。これは、Doctrine2を備えたPHPであろうとJPAのJavaであろうと、私が従うガイドラインでもほとんどありません（Doctrine2はJPAに大きく似ているため）。

追加の抽象化が必要な場合、Doctrine2はすでにリポジトリを使用する可能性を備えています（リポジトリは非常に似ているか、DAOと等しく、ビジネス用語とロジックに重点を置いている可能性があります）。基本クラスの教義 orm entityRepositoryがあります。 EntityManager＃getRepository（$ entityName）のドクトリンを呼び出すと、そのエンティティのカスタムリポジトリクラスを構成したかどうかがわかります。そうでない場合は、Doctrine orm entityRepositoryをインスタンス化します。メタデータのエンティティのカスタムリポジトリクラスを構成できます。たとえば、docblock annotations：@entity（...、repositoryclass = "my project domain userrepository"）。このようなカスタムクラスは、EntityRepositoryから継承し、親コンストラクターを適切に呼び出す必要があります。基本クラスには、すでに基本的な発見*機能が含まれています。

ローマ

Answer 3

また、あなたの研究でSymfonyを検討してください。 ORM（Propel/Doctrine）を使用するか、独自のデータモデルを作成することができます。データ関係をバイパスし、必要に応じて直接SQLを使用することもできます。

1または2の懸念に対処するために、私は個人的にプロジェクトでORMを使用し、必要に応じてそれをバイパスします。そして、Symfonyの方が良いので、必要に応じて教義とPropelまたは自分のクラスを切り替えることができます。

Pros:
1) faster development. easier to maintain. generally more secure and consistent. easy to switch databases should you ever need to.(from MySQL to Oracle, etc). 

2) Faster runtime. Less dependency.

Cons:
1) Slower runtime and larger memory footprint. Dependency on other projects.
2) (reverse the pros for #1) 

Answer 4

私の考えは、PIX0Rの応答に似ています。ただし、プロジェクトがコントローラーでEntityManager/DQLを直接使用できるように十分に小さい場合、Doctrine 2はプロジェクトの場合は過剰になり、小さい/単純なシステムを考慮する必要があります。

Answer 5

私の経験では、コントローラーに永続的なレイヤーロジックを書くことは、技術的な負債の形で私を悩ませるために常に戻ってきました。この一見小さな決定は、小規模プロジェクトでさえ、将来的には避けられない潜在的に大規模な再導入を引き起こす可能性があります。理想的には、適切なモデルと再構成された非常に薄いコントローラーをコピーして貼り付けて、CRUDコントローラーを繰り返し作成する必要がないようにすることができますが、これらのコントローラーのカスタマイズも可能です。私の意見では、これは懲戒処分され、永続的な層を可能な限りアプリケーションから抽象化することによってのみ達成できます。特にクリーンルームのコントローラーでそれを行うオーバーヘッドは最小限であるため、アドバイスしない正当な理由はわかりません。