3

メソッドには常に a が表示DbContext.SaveChanges()されUnitOfWork.Commit()ます。しかし、DbContext からエンティティをフェッチしてプロパティを変更するUnitOfWork.Commit()と、新しいエンティティ値が検証なしでデータベースに書き戻されます。

統合された を使用することは避けますDbContext.Configuration.ValidateOnSaveEnabled = true;。

現在、UnitOfWork-Pattern は使用していません。Service クラスのすべての挿入/更新操作で検証を実行し、検証が成功した場合、リポジトリは を呼び出しますDbContext.SaveChanges()。

UnitOfWork.Commit()無効なエンティティを回避するには? この回答で示唆されているように、ASP.NET MVC コントローラーで UnitOfWork オブジェクトを使用すると、作業 単位はどこに属しますか? ...検証が行われたという保証はありません。

4

2 に答える 2

0

検証とデータ保存を混在させないことを好みます。もちろん、エンティティはデータベースに保存する前に検証する必要がありますが、これは保存時に検証する必要があるという意味ではありません。

アプリケーションによっては、たとえば単体テスト、一部の UI アクション、ASP.NET MVC でのリモート/クライアント側の検証など、コンテキストの外部で検証が必要になる可能性がありますが、おそらくすべてのアクションでデータのコミットが必要になるわけではありません。

おそらく、影響を受けるすべてのエンティティを検証して、保存するよりも良いでしょうか? EF と同じ属性を使用するため、既定の組み込みの ASP.NET MVC 検証を使用すると簡単です。もちろん、サードパーティの検証フレームワークを使用するとさらに簡単になります。

注意: また、一部のエラーは保存しないと処理できないことも忘れないでください。通常は制約違反であり、ロジックがトリガーされます。そのため、検証ではそのエラーも処理する必要があります。残念ながら、EF がそのエラーをどのように処理するかはわかりません。私の開発では、通常、その制約ごとにハードコーディングを行いました。

于 2012-07-16T19:03:14.310 に答える
0

あなたは基本的にそこにいます。UoW を使用している場合、リポジトリの更新は、データ ストアへのコミットとは無関係になります。単純にDbContext.SaveChanges()新しいUnitOfWork.Commit()メソッドに移動して (またはDbContext.SaveChanges()コミット メソッドとして直接使用して)、検証ロジックをリポジトリのInsert/Updateメソッドに残します。

using (var uow = new UnitOfWork())
{
  var e1 = new Entity() { ... };
  repo.Insert(e1);  // validates e1 immediately

  var e2 = GetExistingEntity();
  e2.Value = 42;
  repo.Update(e2);  // validates e2 immediately
}
于 2012-07-16T16:44:05.493 に答える