0

それで、私は新しいソフトウェアに取り組んでいますが、データベースをブラウンフィールド化するしかありません。意味のある場合は Entity Framework を使用したいと思います。

ここに私のジレンマがあります:

  • テーブルは非常に広く、これを変更することはできないため、クエリを実行するデータセットの幅を制限するために射影を多用することになるでしょう。
  • 意味のあるナビゲーション プロパティを利用したい
  • 私が見た限りでは、多くの人が、プロジェクト全体に対して 1 つの DbContext クラスがあるモデルを使用しています。

そう、

私はこれらの長所と短所を比較検討しており、確立されたベスト プラクティスはどのようなものになるのだろうかと考えています。

  • 1 DbContext を使用します。
    • ここには、1 つのコンテキスト クラス内のデータの投影の束を伴う、大量の「汚染」が存在する可能性があります。これはメンテナンスの悪夢になりそうです。
  • 私のプロジェクションをまったく dbset にしないでください。単純な古いオブジェクトにして、新しい MyProject {..} を選択してください。
    • これにより、プロジェクションをモジュール固有のアセンブリと名前空間に保持できるという利点が得られますが、ナビゲーションや遅延読み込みなどを取得できなくなりました。
  • 悪になる?? 複数の DbContext を使用しますか?
    • ここでのメンテナンスの話がどのように見えるかはよくわかりませんが、私はこの方向に傾き始めています. それに関する私の最大の問題は、流れに逆らって泳いでいるように感じるということです.これを行う人はあまりいないようですが、大規模なシステムでは、これが最良の選択肢のようです.

考え?

4

1 に答える 1

0

アプリケーションの異なるレイヤー間のデータ転送には、POCO または DTO を使用する必要があると思います。ViewModel を使用してデータを View に送信します。

このシナリオでは、リポジトリ パターンと UoW を使用して、より優れた効率的なアーキテクチャを実現することを検討してください。リポジトリまでナビゲーション プロパティの使用を制限します。そうしないと、レイヤー間で転送するときにエンティティが重くなります (POCO または DTO を使用します)。

上記のようにしている場合、複数の DbContext を使用してもメリットはないと思います。ありがとう。

于 2013-07-09T03:14:41.520 に答える