EFからADO.NETへの移行

ado.net asp.net-mvc-3 dapper entity-framework

質問

asp.net mvc 3アプリケーションのいくつかのモジュール:今はPOCOクラスでEFを使用していますが、将来はADO.NETやその他のORMツール(DAPPER 。ネット)。

私たちが直面している問題は、コレクションクラスがEFを介してロードされることに依存するビュー、これらのエンティティクラスが他のADO.NETまたはORMツールを使用したEFとまったく同じ方法でロードされるべき戦略。

私が望むのは、データアクセスレイヤーの変更を最小限に抑えて、EF&ADO.NETを切り替えることです。私のViewsがそれによって効果を発揮するのを望まないからです。

受け入れられた回答

リポジトリデザインパターンを使用して、データアクセスレイヤの実装を非表示にする必要があります。リポジトリは、同じPOCOを返し、フードの下でどのデータアクセスレイヤーを使用しているかにかかわらず、同じ操作規約を持ちます。これは、実際のP​​OCOを使用していて、遅延ロードのための仮想メソッドを持たない場合にはうまく動作します。この作業を行うには、エンティティ上の依存コレクションのロードを明示的に処理する必要があります。


人気のある回答

私がこれまで見てきたことは、ORM / DALから別のORM / DALへのシームレスな移行です。ケビンによって提案されたレポジトリのパターンは大きな助けであり、前提条件でもあります(+1)。しかし、それにもかかわらず、各ORMにはドメイン層のフットプリントがあります。 EFを使用すると、おそらく仮想プロパティ、データの注釈、または簡単に忘れてしまったものを使用して、簡単に適合する(およびそうでない他の人を却下する)検証フレームワークを使用します。ジョイン・テーブルをまたがってマップするEFの能力に頼っているかもしれません。あなたがEFのためにしない (しかししたいことがある)ことがあるかもしれません

(EFコンテキストの上で足場を実行するツールはもちろん、ロックインをより緊密にするツールもあります。)

あなたの状況で私がするかもしれない何らかの事は(私があなたにとって明白なことを言っているなら、私を許してください)

  • EFを最適に使用してください。 (ベストマッピング、ベストアソシエーション、...)将来のための準備はいいですが、 YAGNIパターンに簡単に堕落します。
  • linq + EFに堪能な方:EFで不必要にパフォーマンスを殺す方法はたくさんあります。 EFが十分だとしましょう!
  • ストアドプロシージャ、並列化、バックグラウンド処理、データボリュームの削減などの高性能のための代替案を探し続け、要件(機能的および非機能的)が十分に明確なときに1つを選択します。
  • おそらくあなたのビューに役立つDTOの抽象レイヤーを導入し、将来は別のORMまたはADOによって容易に実現できます。
  • POCOをインタフェースとして公開します。これは後で他のオブジェクトによって実装することができます。


ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow