3

我希望能够从我的服务类中执行验证。我有一个看起来像这样的控制器动作：

public ActionResult Edit(Post post)
{
    if(!ModelState.IsValid)
       return View();

    _postDataService.SavePost(post);

    return View("Index");
}

我不喜欢我的 _postDataService.SavePost() 可以保存无效数据的事实，我想将模型验证移至我的 _postDataService.SavePost() 方法。我的问题是最优雅的方法是什么？如果我将模型验证移至我的 Service 方法，我如何将模型错误返回给我的控制器？最后，像电子邮件地址的唯一性这样的模型验证会去哪里，因为它需要一些数据访问？在我看过的所有类似问题中，没有一个给出直接的方法来做到这一点。

我也考虑过这个解决方案，但这篇文章很旧，我觉得它不是最新的。

4

1 回答 1

3

我假设您通过在 Post 模型/实体类中的属性上放置属性来进行验证。如果是这样，您可以通过执行以下操作在您的服务层中进行验证：

var results = new List<ValidationResult>();
var isValid = Validator.TryValidateObject(post, 
    new ValidationContext(post, null, null), results, true);

这本质上是默认模型绑定器在为控制器/操作验证和配置 ModelState 对象时所做的事情。

这种方法的美妙之处在于您不必从服务层返回验证错误。您将仅依靠默认的模型绑定器自动执行上述代码。如果有人试图在不检查 ModelState.IsValid 的情况下调用该操作，只需让您的服务方法抛出异常以提醒他们。

评论后更新

是的，我的回答建议进行两次验证。

我感觉如何？我不介意。我们将 Entity Framework 4.1 与 MVC 一起使用，并且不使用 MVC 中的实体。相反，我们使用自动映射器将实体 DTO 到单独的视图模型层中。我们的 EF 实体也使用 ValidationAttributes 进行装饰，EF 在任何 DbContext.SaveChanges() 操作期间都会自动对其进行评估。我们在视图模型类的属性上应用了非常相似的验证属性。这可能看起来并不干，而且肯定存在重叠，但在某些情况下，UI 端的验证属性可能与域模型中的验证属性不同。

我们不在服务层进行验证。我们的服务层只是一个应用程序流协调器，不负责业务规则。但是，验证仍然在我们的应用程序中发生两次。首先，通过默认模型绑定器，违反 viewmodel 验证规则。然后，如果事务进入 EF，则对实体执行验证。所以我们实际上是在验证 2 个单独的层。

但是，如果您考虑一下，您确实在这里解决了两个不同的问题。在 UI 中，您希望 MVC 向用户显示验证消息。ModelState 非常适合这一点，因为它与 MVC 验证（模型绑定/jquery/不显眼/客户端验证/等）很好地挂钩。

相反，在域中，您正在保护数据完整性并执行业务规则。域不关心向用户显示消息。据它所知，客户端可能是一台机器、WCF 服务或其他东西。域的作用是防止事务发生，并且（在我们的例子中）抛出异常而不是悄悄地尝试“与”客户端“合作”。

于 2012-01-04T10:51:10.640 回答