验证多层应用程序的输入数据的最佳实践

Jig*_*hah 8 java design-patterns multi-tier

在我们的应用程序中,我们有各种层 服务层,DAO层和操作(struts应用程序).

数据从一个层传递到另一个层.

我们应该在哪里理想地进行输入验证?

比如,用户ID,电话号码来自UI,它们是强制性的.所以我们已经在客户端进行验证.

现在,根据我的意见,这就是你所需要的.没有其他地方应该验证.

但我的一位同事认为,如果客户直接提出请求会怎样.所以我们还需要添加Actions.

现在,在道也,同样的方法被用于其他一些行动,并没有验证,

或者,说服务层,它可能会被曝光,比如说作为Web服务,所以你也可以进行验证.

基本上,他建议......我们到处都有验证.这对我来说没有意义.它跨层重复.

什么是理想的方法?说验证可能是简单的空检查或一些复杂的验证.

Cle*_*t P 12

同意Pangea,您肯定应该在客户端和服务端点进行验证.

我想补充一点,验证的概念是"快速失败".您可以为每个层添加验证,以便用户或调用者可以立即获得有关调用失败的原因的反馈,而不是可能启动事务,进行复杂查询并执行写操作以查找字段太短.

在客户端,您需要尽可能多的验证,这样您就不会浪费用户的时间,带宽和服务器端资源(在许多情况下会产生争用).但是,您通常无法在客户端进行所有验证(例如,检查是否已经在注册时使用了这样的用户名),因此您希望选中此选项并在发布时立即返回正确的错误消息点击服务层.

在服务器层,您要假设所有输入都是潜在危险和不正确的(并且它们通常是时间).我认为最好是更全面和积极地验证服务层上的输入,因为这是你的最后一道防线.如果你在客户端省略一两个验证,你只需要一个好的故障处理机制让用户知道什么是错的.如果您错过了服务端的某些内容并发生灾难,则可能意味着需要数小时或数天的调试并尝试恢复数据库备份.

还有一些检查在数据库级别完成,这些检查强制执行诸如引用完整性之类的事情.我通常会在尝试写入之前尝试尽可能多地检查它们,因为解释各种RDBMS的错误消息并尝试将它们转换回用户可理解的术语通常很难,如果不是不可能的话.


Ara*_*ram 5

如果您的应用程序提供了多个入口点(UI或系统到系统接口或批处理系统),那么您应该在所有这些边缘以及到达服务层之前清理(空检查,格式化检查,必需等)您的数据.但这并不意味着您需要复制验证逻辑.您可以使用允许集中验证的框架.一些示例验证框架可以在这篇文章中找到.

但是,业务验证应属于您的域层,并且应保留在域服务层或域对象中.

我不同意您应该在DAO中执行验证.DAO应该负责CRUD操作.如果他们做得更多,那么你就会有漏洞.如果您必须批量处理东西,那么您应确保批处理通过服务层,以便您的批处理也经历相同的验证.