大多数（几乎所有？）验证框架都基于读取对象的属性值并检查它是否遵守验证规则。
如果我们将有效参数传递给对象的构造函数、属性设置器和其他方法，对象似乎是完全有效的，并且不需要检查属性值！
验证参数而不是属性不是更好吗？
在将参数传递到对象之前可以使用哪些验证框架来验证参数？
更新
我正在考虑客户端调用服务方法并传递一些数据的情况。服务方法必须检查数据、创建/加载域对象、执行业务逻辑和持久化更改。
似乎大多数时候数据都是通过数据传输对象来传递的。并且使用属性验证是因为 DTO 只有在网络基础设施创建后才能验证。
【问题讨论】：
标签： validation oop architecture
这个问题可以扩展到更广泛的主题。先来看看Martin Fowler has said：
一个数据副本位于数据库本身。这个副本是持久的 数据的记录，所以我称之为记录状态。
另一个副本位于应用程序的内存记录集中。这个数据 仅与应用程序之间的一个特定会话相关 和数据库，所以我称之为会话状态。
最后的副本在于 在 GUI 组件本身内部。严格来说，这是他们的数据 在屏幕上看到，因此我称之为屏幕状态。
现在我假设您正在讨论会话状态的验证，无论是验证对象属性还是验证参数更好。这取决于。首先，这取决于你是否使用Anemic or Rich Domain Model。如果您使用anemic domain model，则将清楚验证逻辑将驻留在其他类中。
其次，这取决于您构建什么类型的对象。框架/操作/实用程序对象需要对对象属性进行验证。例如：C# 的 FileStream 对象，其中流类需要具有文件路径、内存指针、文件访问模式等的有效属性。您不希望每个使用该实用程序的开发人员都预先验证输入或它将在一次操作中崩溃，并给出错误的错误消息而不是fail fast。
第三，您需要考虑“参数可以有多种来源/形式”，而“类/对象属性只有1个定义”。您需要在每个输入源处放置参数验证，而对象属性验证只需要定义一次。但是您还需要了解对象的状态。对象可以在某些状态下（草稿模式）有效，而在其他状态下（提交模式）无效。
当然你也可以将验证添加到其他状态级别，例如数据库（记录状态）或 UI（屏幕状态），但它也有不同的优缺点。
在将参数传递到对象之前，可以使用哪些验证框架来验证参数？
C# 的 ASP.Net MVC 可以在控制器级别构造对象之前执行一种parameter validation（用于数据类型）。
这完全取决于您要制作的架构和对象类型。
【讨论】：
根据我的经验，此类验证是在处理复杂的验证规则和Parameter object 时完成的。由于我们需要保留Separation of concerns - 验证逻辑不在对象本身中。这就是为什么 - 是的，我们
我们真的需要它
更有趣的是——为什么要构造昂贵的对象，然后再验证它们。
【讨论】：