3

我总是DbContext.SaveChanges()在UnitOfWork.Commit()方法中看到一个。但是，当我从 DbContext 获取实体并更改属性时，UnitOfWork.Commit()会将新实体值写回我的数据库，而无需任何验证。

我会避免使用集成的DbContext.Configuration.ValidateOnSaveEnabled = true;.

目前我不使用 UnitOfWork-Pattern。我对我的服务类中的每个插入/更新操作运行验证，如果验证成功，存储库调用DbContext.SaveChanges()。

如何避免UnitOfWork.Commit()使用无效实体？如果我在 ASP.NET MVC 控制器中使用 UnitOfWork 对象，正如它在此答案中所建议的那样： 在哪里工作单元属于 w/EF4、IoC (Unity) 和存储库？ ...无法保证验证已完成。

4

2 回答 2

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 回答
0

我更喜欢不要混合验证和数据保存。当然，实体必须在保存到数据库之前进行验证，但这并不意味着它们必须在保存时进行验证。

根据应用程序，可能需要在上下文之外进行验证，例如在单元测试、某些 UI 操作、ASP.NET MVC 中的远程/客户端验证等中，可能并非所有这些操作都必须导致提交数据。

也许验证所有受影响的实体而不是保存它更好？使用默认的内置 ASP.NET MVC 验证很容易，因为它使用与 EF 相同的属性。当然，如果您使用第三方验证框架，那就更容易了。

备注：也不要忘记，有些错误不保存是无法处理的，通常是违反约束和触发逻辑。所以验证也必须处理这些错误。不幸的是，我不知道 EF 如何处理这些错误，在我的开发中，我通常对每个约束进行一些硬编码。

于 2012-07-16T19:03:14.310 回答