参数验证与属性验证

Question

大多数（几乎所有？）验证框架都基于读取对象的属性值并检查它是否符合验证规则。

1. 我们真的需要它吗？

如果我们将有效参数传递给对象的构造函数，属性设置器和其他方法，则对象似乎完全有效，并且不需要进行属性值检查！

1. 验证参数而不是属性是否更好？

2. 在将参数传递给对象之前，可以使用哪些验证框架来验证参数？

更新

我考虑客户端调用服务方法并传递一些数据的情况。服务方法必须检查数据，创建/加载域对象，执行业务逻辑并保持更改。

似乎大部分时间数据都是通过数据传输对象传递的。并且使用属性验证是因为DTO只有在网络基础架构创建后才能进行验证。

Answer 1

这个问题可以扩展到更广泛的主题。首先，让我们看看Martin Fowler has said：

  

数据的一个副本位于数据库本身。这个副本是持久的   记录数据，所以我称之为记录状态。

     

另一个副本位于应用程序内的内存记录集中。这个数据   仅与应用程序之间的一个特定会话相关   和数据库，所以我称之为会话状态。

     

最后的副本在于   在GUI组件本身内部。严格来说，这是他们的数据   在屏幕上看到，因此我将其称为屏幕状态。

现在我假设您正在讨论会话状态的验证，验证对象属性或验证参数是否更好。这取决于。首先，这取决于您是否使用Anemic or Rich Domain Model。如果使用anemic domain model，则会清除验证逻辑将驻留在其他类中。

其次，它取决于您构建的对象类型。 Framework / operation / utility对象需要对object属性进行验证。例如：C＃的FileStream对象，其中流类需要具有文件路径，内存指针，文件访问模式等的有效属性。您不希望每个使用该实用程序的开发人员事先验证输入或者它将在一次操作中崩溃，并提供错误的错误消息，而不是fail fast。

第三，你需要考虑“参数可以有多种来源/形式”，而“类/对象属性只有1个定义”。您需要在每个输入源上放置参数验证，而对象属性验证只需要定义一次。但是你还需要了解对象的状态。对象在某些状态（草稿模式）中有效，而在其他状态（提交模式）无效。

当然，您也可以将验证添加到其他州级别，例如数据库（记录状态）或UI（屏幕状态），但它也有不同的优点/缺点。

  

在将参数传递给对象之前，可以使用哪些验证框架来验证参数？

C＃的ASP.Net MVC可以在构建到控件级别的对象之前执行一种parameter validation（对于数据类型）。

结论

这完全取决于您想要制作的体系结构和类型。

Answer 2

根据我的经验，这些验证是在处理复杂的验证规则和Parameter object时完成的。由于我们需要保留Separation of concerns - 验证逻辑不在对象本身中。这就是原因 - 是的，我们

  

我们确实需要它

更有趣的是 - 为什么要构建昂贵的对象，然后验证它们。