客户端验证（表示层中的验证）
即使事实来源是域模型，并最终必须在域模型级别进行验证，验证仍可在域模型级别（服务器端）和 UI（客户端）进行处理。
客户端验证对于用户来说是一种极大的便利。 它节省了时间，让用户不必浪费时间等待服务器往返，服务器有可能返回验证错误。 从商业角度而言，即使每次只有几分之一秒，但如果每天发生几百次，也会耗费大量的时间和成本，带来很多不必要的烦恼。 直接且即时的验证使用户能够更高效地工作，并生成更好的质量输入和输出。
与视图模型和域模型不同一样，视图模型验证和域模型验证可能类似，但用途不同。 如果担心 DRY（请勿重复自己原则），请考虑在这种情况下，代码重用也可能意味着耦合，在企业应用程序中，更重要的是不要将服务器端与客户端耦合在一起，而不是遵循 DRY 原则。
即使使用客户端验证，也应始终在服务器代码中验证命令或输入 DTO，因为服务器 API 是可能的攻击途径。 通常，这样做是最好的选择，因为如果你有客户端应用程序，从 UX 的角度来看，最好是主动，不允许用户输入无效的信息。
因此，在客户端代码中，通常会验证视图模型。 您还可以在将客户端输出的 DTO 或命令发送到服务之前进行验证。
客户端验证的实现取决于要生成的客户端应用程序类型。 如果在 MVC Web 应用程序中验证数据，其中大多数代码在 .NET 中与 SPA Web 应用程序在 JavaScript 或 TypeScript 中使用验证代码，则情况会有所不同。
其他资源
ASP.NET Core 应用中的验证
SPA Web 应用中的验证（Angular 2、TypeScript、JavaScript、Blazor WebAssembly）
验证。 Breeze 文档。
https://breeze.github.io/doc-js/validation.htmlASP.NET Core Blazor 窗体和输入组件 \ </aspnet/core/blazor/forms-and-input-components>
总之，以下是验证方面最重要的概念：
实体和聚合应确保其自身的一致性，并“始终有效”。 聚合根负责同一聚合中的多实体一致性。
如果您认为实体需要进入无效状态，请考虑采用不同的对象模型，例如，使用临时 DTO，直到创建最终域实体。
如果需要创建多个相关对象（例如聚合），并且它们仅在创建所有对象后才有效，请考虑使用工厂模式。
在大多数情况下，在客户端中具有冗余验证是好的，因为应用程序可以主动。
