1

私の WebApi プロジェクトでは、EF6 を使用し、Uow および一般的なリポジトリ パターンに従います。また、モデルを dto にマッピングし、その逆も行います。

現在、作成時に次のように設定していますdbContext。

this.Configuration.LazyLoadingEnabled = false;
this.Configuration.ProxyCreationEnabled = false;

AsNoTrackingまた、データベースからデータをフェッチするときにも使用します。

データベースを更新するとき、私は dbContext を直接使用して、小さなエンティティ (つまり、関係がない) を処理するときにエンティティをアタッチしています。複雑なエンティティ (つまり、関係がある) には GraphDiff を使用します。

プロキシと追跡を有効にし、無効にしても、DB に送信される SQL ステートメントには、実際に変更された列だけではなく、テーブルのすべての列が含まれていることに気付きました。

ただし、GraphDiff は変更を DB に保存する前にエンティティを再度ロードしています。この場合の SQL ステートメントには、すべての列も含まれています。これは正しい動作ですか？

私のシナリオでは、切り離されたエンティティを扱っているので、プロキシと追跡を無効にしても安全ですか?

4

1 に答える 1

0

はい、そうだと思います。これは、EF がオプティミスティック コンカレンシーを処理する方法です。

オプティミスティック コンカレンシーでは、エンティティが読み込まれてからデータベース内のデータが変更されていないことを期待して、エンティティをデータベースに楽観的に保存しようとします。データが変更されたことが判明した場合は、例外がスローされ、保存を再試行する前に競合を解決する必要があります。

EF がこれを確認する唯一の方法は、すべての列を読み込み、変更を確認し、最後の読み込みと保存の間にレコードが変更された場合は保存をブロックすることです。これを確認してください。

タイムスタンプ列がない場合は、この属性 (詳細はこちら)[ConcurrencyCheck]を使用して、その特定の列がレコードが変更されたかどうかを理解するために使用する列であることを EF に通知できます。これにより、同時実行チェックのためにすべてをロードすることを回避できます。

それが役に立てば幸い ：）

于 2016-03-18T09:15:10.580 に答える