为什么要使用FluentValidation而不是ASP.NET MVC验证？

Question

在什么情况下您会选择FluentValidation (FV)而不是ASP.NET MVC 3？

FV相对于MVC的优势是什么？我意识到我们在使用后者时需要编写更多的代码，并且可能会在代码中添加数据注释。此外，使用FV编写自定义验证似乎比MVC更容易。然而，使用MVC可以使用数据注释并插入jQuery验证。

那么，在您看来，什么因素会使您选择其中之一？是否有情况下您会同时使用两者？

- DavidS

Answer 1

流畅验证(Fluent validation)是一种设置专用验证器对象的方法，当您希望将验证逻辑与业务逻辑分开处理时使用。面向方面编程 (AOP) 范式可以在系统内部分离横切关注点(cross-cutting concerns)，其中验证就是此类关注点之一。分离验证有助于清理您的域代码并使其更加协同，同时还提供了一个单一的位置来查找验证逻辑。

MVC注释驱动的验证(annotation-driven validation)是一种非常“便宜”的方式，可以在不创建专用验证器对象、创建组织它们的验证系统以及将其全部连接在一起的情况下，将一些基本验证引入应用程序中。它非常容易设置，但可能会使您的域对象不够干净。

对于所有验证逻辑都可以使用注释处理的小型系统，我建议只使用注释，因为它们非常容易设置。对于更大、更复杂的系统，我建议使用专用验证器对象分离验证关注点。

我个人喜欢同时使用这两种方法：将验证属性添加到 ViewModel 类(这意味着注释不会混乱我的域对象)，以及在我的域层中具有专用验证器对象。这是少量重复，但是使用注释非常快速和容易，我认为它值得额外的维护成本。

- Steve Wilkes

---

特别是第三和第四段，我打算点个赞。我经常看到人们把事情复杂化，在现实世界中（一个人必须在某个时候交付成果的地方），让解决方案适应问题非常重要。你的方法听起来是值得赞赏的实用方法。 - Tom Chantler

点到了。然而，当您说“MVC注释驱动验证是将一些基本验证融入应用程序的非常'便宜'的方法”时，我假设您所说的是开箱即用的验证，即非自定义验证。否则，我们一定做错了什么，因为我们花费了时间以MVC方式在OP链接中提供的方式进行自定义验证。在后一个链接中，确实有您所谈到的关注点分离，尽管有数据注释，但自定义验证类本身是独立的。 - DavidS

@DavidS - 我确实是指内置的验证器类型，尽管我认为一旦你克服了使用自定义验证器的难点，它们也会非常便宜。FV通过类级别的“Validator”属性为您提供“一个验证系统，将[验证器]组织起来并将其全部插入”，从而减少了麻烦；我仍然认为决定采取哪种路线的主要因素应该是所需验证的复杂性。 - Steve Wilkes

谢谢你的回答。我们最初使用了FV，但后来我决定使用MVC验证，因为我们需要客户端验证。也许只有时间和经验才能告诉我们什么是对的，什么是错的。 - DavidS