FluentValidation中间件在.NETCore WebAPI中是否足够，还是应该再次在服务层中进行验证？

Question

我有一个非常简单的3层ASP.NET Core WebAPI应用程序：

1. Domain -使用Entities、Data interfaces、Services和DTO对象(它们是唯一的输入和输出对象)。因此，“域的接口”是接受输入DTO并返回输出DTOs.
2. Infrastructure ( Data interfaces (数据存储库))和CodeFirst Migrations.
3. WebAPI -标准ASP.NET Core3.1WebAPI项目的实现的服务。

WebAPI项目在控制器中返回“输出”DTO。对于接受有效负载的端点，使用“输入”DTO。控制器与来自域的服务非常相似。控制器向世界公开域服务(显然是域的接口)。

但接下来是验证..。我熟悉FluentValidation和ASP.NET核心管道--它是一个很棒的中间件：

        services.AddControllers()
            .AddFluentValidation(opt =>
            {
                opt.RegisterValidatorsFromAssemblyContaining(typeof(PersonInputValidator));
            });

我为每个“输入”DTO实现了验证，这很好，但是.我不确定这是否足够。如果您选择了任何服务类，则几乎没有验证。.NET核心中间件在技术上验证了控制器的输入。

我应该再次在服务中“双重验证”吗？如果是这样的话，是否有一种顺利的方法来重用我已经拥有的验证器？

Answer 1

你不应该运行两次验证。应该验证来自web的数据。如果您在web之外的任何其他接口中使用您的服务，您也可以在那里实现您的流利验证。下面是实现fluent验证的一个很好的示例：https://github.com/jasontaylordev/NorthwindTraders

Answer 2

对于服务层和表示层，我通常会在服务层执行FV实现/dto验证。这样，服务就可以被重用，验证也随之进行了。它还允许您保持您的控制器倾斜。在您的控制器中，可能存在特定于表示层的检查/验证的范围，例如模型绑定失败。但是，这可能只是一个基本的模型状态实现，我不会让FV了解这一点。

Answer 3

FluentValidations可以在控制器中使用，同时也可以使控制器保持精瘦。在业务层，还可以添加其他验证规则，但模型状态是在作为系统网关的WebApi级别上检查的。FluentValidation使用中间件，所以如果验证失败，控制器甚至不会被击中。我还建议实现中间件，将业务层抛出的任何异常转换为适当的http状态代码，这也会使控制器非常干净。在业务层中，有时也会使用验证规则，例如当您希望检查是否存在依赖数据时。