2

移行の提案が必要asp.netmvc3アプリケーションのいくつかのモジュール：現在、POCOクラスでEFを使用していますが、将来、一部のパフォーマンス駆動型モジュールでは、ADO.NETまたはその他のORMツール（DAPPERの可能性があります）に移行する必要があります。ネット）。

現在直面している問題は、EFを介して読み込まれるコレクションクラスに依存するビュー、他のADO.NETまたはORMツールを使用したEFとまったく同じ方法でこれらのエンティティクラスを読み込むために使用する戦略です。 。

私が望んでいるのは、データアクセス層での変更を最小限に抑えてEFとADO.NETを切り替えられるようにすることです。これにより、ビューが有効になりたくないからです。

4

3 に答える 3

2

データアクセス層の実装を非表示にするには、リポジトリデザインパターンを使用する必要があります。リポジトリは、内部で使用しているデータアクセス層に関係なく、同じPOCOを返し、同じ操作コントラクトを持ちます。これで、遅延読み込み用の仮想メソッドがない実際のPOCOを使用している場合、これは正常に機能します。これを機能させるには、エンティティへの依存コレクションのロードを明示的に処理する必要があります。

于 2012-04-10T12:22:09.533 に答える
2

これまで見てきたことですが、あるORM/DALから別のORM/DALへのシームレスな移行は幻想です。Kevinによって提案されたリポジトリパターンは大きな助けであり、前提条件でさえあります（+1）。それでも、各ORMにはドメインレイヤーにフットプリントがあります。EFを使用すると、おそらく仮想プロパティ、おそらくデータアノテーション、または簡単に忘れられる検証フレームワークを使用します。これは簡単に適合します（そして適合しない他のフレームワークを却下します）。結合テーブル間でマップするEFの機能に依存する場合があります。EFのためにあなたがしない（しかししたい）ことがあるかもしれません。

（EFコンテキスト上でスキャフォールディングを実行するツールは言うまでもありません。これにより、ロックインがさらに厳しくなります。）

私があなたの状況でするかもしれないいくつかのこと（私があなたのために明白なことを述べているなら私を許してください）

  • EFを最適に使用してください。（最良のマッピング、最良の関連付け、...）将来への準備は良いですが、YAGNIパターンに簡単に縮退します。
  • linq + EFに習熟する：EFでパフォーマンスを不必要に殺す方法はたくさんあります。EFで十分だとしましょう！
  • ストアドプロシージャの使用、並列化、バックグラウンド処理、データ量の削減など、高性能の代替手段を探し続け、要件（機能的および非機能的）が十分に明確な場合に1つを選択します。
  • たぶん、現在あなたの見解を提供するDTOを備えた抽象化レイヤーを導入し、将来的には別のORMまたはADOによって容易に実現することができます。
  • POCOをインターフェースとして公開します。これは、後で他のオブジェクトによって実装できます。
于 2012-04-10T20:47:54.173 に答える
0

これらの答えの両方に追加するだけです...

私は常にソリューションを次の基本的なプロジェクトに構造化しています。

  • フロントエンド（通常はasp.net MVC Webアプリ）、
  • ビジネスプロセスを備えたサービス/コア、
  • アプリケーションモデルのPOCOと通信インターフェイスを備えたオブジェクト-他のすべてのプロジェクトによって参照されるため、データ交換コントラクトとして機能し、

  • オブジェクトからPOCOインスタンスを返すリポジトリを実装するデータ

  • フロントエンドはオブジェクトとサービス/コアを参照します

  • ServicesCoreはオブジェクトとデータを参照します
  • データ参照オブジェクト
  • オブジェクトはドメインアプリケーションモデルであるため、他のオブジェクトを参照しません

フロントエンドに追加のPOCOが必要な場合は、フロントエンドでビューモデルとして作成し、そのプロジェクトにのみ表示されます（つまり、登録プロセスでは通常、Objects.Userエンティティ（POCO）よりも多くの（そして異なる）プロパティを持つ別のタイプが使用されます）。これらの種類のタイプをObjectsに入れます。

同じことがデータのみのタイプにも当てはまります。追加のプロパティが必要な場合、これらのクラスは通常、同じObjectsToPoco()クラスから継承し、データ型からアプリケーションモードクラスにマップする方法を正確に知っているジェネリックメソッドのような追加のプロパティとメソッドを追加します。

DALの変更

したがって、データアクセスコードを変更する必要があるときはいつでも（@GetArnoldが指摘したように）、異なるライブラリ/フレームワークを使用する異なるデータプロジェクトを提供するだけで済みます。追加のデータ固有のタイプなどもすべてその一部になります...しかし、他のレイヤーとのすべての通信は同じままです。

新しいデータプロジェクトを作成する代わりに、リポジトリコードを変更して既存のプロジェクトを変更し、それらで別のDALを使用することもできます。

于 2012-04-11T10:58:30.887 に答える