在哪种情况下您会选择FluentValidation (FV)而不是ASP.NET MVC 3 way？为什么使用fluentvalidation代替ASP.NET MVC验证
FV优于MVC的优点是什么？我意识到，对于后者，我们必须编写更多的代码，并且可以通过数据注释清除代码。而且，使用FV编写自定义验证似乎比MVC更容易。但是，使用MVC，可以使用数据注释并插入jQuery验证。因此，您认为什么会让您选择一种优先于另一种？有甚么情况下甚至会同时使用两者？
流利的验证是设置专用验证器对象的一种方式，您可以在验证逻辑与业务逻辑分开时使用验证器对象。面向方面编程（AOP）范式可以分离系统内的交叉问题，验证就是这样的一个问题。分离验证有助于清理域代码并使其更加紧密，并为您提供一个位置来查找验证逻辑。
MVC注释驱动的验证是一种非常“便宜”的方式，可以在应用程序中获得一些基本的验证，而不必担心创建专用的验证器对象，创建验证系统来组织它们并将它们组合在一起。设置起来非常简单，但可以使您的域对象不那么干净。
对于所有验证逻辑都可以使用注释进行处理的小型系统，我建议仅使用注释，因为它们非常易于设置。对于更大，更复杂的系统，我建议使用验证器对象分隔验证问题。
我个人喜欢使用两种方法：为ViewModel类添加验证属性（这意味着注释不会混淆我的域对象），以及在我的域图层中有专用的验证器对象。这是少量的重复，但使用注释非常快速和容易，我觉得值得额外的维护成本。
+1尤其适用于第三和第四段。我经常看到人们过于复杂的事情，并且在现实世界中（实际上必须在某个时刻提供某些东西），使解决方案适合这个问题很重要。你的听起来像一个可爱的实用方法。 – 2011-06-07 14:57:52
采取了点。然而，当你说“MVC注释驱动验证是一种非常'便宜'的方式来获得应用程序中的一些基本验证”时，我假定你正在谈论即开即用验证，即非自定义验证。否则，我们必须做一些错误的事情，因为我们需要花时间按照OP中的链接提供的MVC方式进行自定义验证。在后面的链接中，有关于您所讨论的这种关注的分离，尽管当然有数据注释但自定义验证类本身是分开的。 – DavidS 2011-06-07 15:15:47
@DavidS - 我的意思是内置的验证器类型，是的 - 虽然我假设一旦你完成了使用自定义验证器的工作，他们也会很便宜。 FV通过类级别的Validator属性为您提供“一个验证系统，用于组织[验证者]并将它们连接在一起”，从而减少麻烦;我仍然认为确定采取哪条路线的驱动因素应该是所需验证的复杂性。 – 2011-06-07 21:13:04