|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-01-14
http://www.matrix.org.cn/resource/article/44/44153_Hibernate%20Validator%20.html
很使用的技术 . 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2006-01-15
在底层实体类上面建立针对操作逻辑的验证可不是什么好事，藕合性太强了，很坏的味道。不过这种用法算是Hibernate提供的一种方面的功能吧，尽管未必去用它。
|
| 返回顶楼 | |
|
发表时间：2006-01-15
最近接手一个项目，安全性要求很高，所以程序很多校验。从js到action、到业务bean、再到dao、然后是db，每一处都有代码校验，实在是麻烦。
不知道有没有这样的做法，从js到db（或者只到hibernate），只有一个ValidatorObject，但是可以校验每一层的XO对象 |
| 返回顶楼 | |
|
发表时间：2006-01-15
robbin 写道 在底层实体类上面建立针对操作逻辑的验证可不是什么好事，藕合性太强了，很坏的味道。不过这种用法算是Hibernate提供的一种方面的功能吧，尽管未必去用它。
比如说一个 应用 使用 JSF + Hibernate ,以前看过一篇文章(在那里看的忘了 )说 实体类只和数据库操作有关,不可以传递到表现层(JSF层), 在表现层可以有一个与实体类向对应的类,用她来操作JSP页面的输入数据,请问 如果在表现层的属性类中 使用验证可以吗. |
| 返回顶楼 | |
|
发表时间：2006-01-15
哦 找到了老兄robbin 你写的文章啦 在这里呢: http://www.hibernate.org.cn/viewtopic.php?t=627
在里面你总结到: robbin 写道 总结：
FormBean是Web层的数据表示，他不能被传递到业务层；PO是持久层的数据表示，在特定情况下，例如Hibernate中，他可以取代VO出现在业务层，但是不管PO还是VO都必须限制在业务层内使用，最多到达Web层的Control，绝不能被扩散到View去。 FormBean和PO之间的数据转化是在Action中进行滴。 那么在FormBean 中使用Hibernate Validator 应该不错吧. |
| 返回顶楼 | |
|
发表时间：2006-01-15
不同的操作很可能需要不同的验证规则，例如经理级别的人访问的时候，限定类型为所有的，员工级别的人访问的时候，限定类型为只有某些类型可见，这个时候你的验证规则根本无法实现。请记住一点：一般来说，数据验证规则往往和业务逻辑关系紧密，更和外部的环境变量关系紧密(例如角色，权限等等)，作为一个底层的实体类是不应该知道这些的，而且就算加上验证规则，也无法实现其验证功能。
Hibernate validator充其量只能做一个最初步的验证，其功能等同于数据库的表字段的constraint，说实话在实际项目中意义并不大。 |
| 返回顶楼 | |
|
发表时间：2006-01-15
robbin 写道 不同的操作很可能需要不同的验证规则，例如经理级别的人访问的时候，限定类型为所有的，员工级别的人访问的时候，限定类型为只有某些类型可见，这个时候你的验证规则根本无法实现。请记住一点：一般来说，数据验证规则往往和业务逻辑关系紧密，更和外部的环境变量关系紧密(例如角色，权限等等)，作为一个底层的实体类是不应该知道这些的，而且就算加上验证规则，也无法实现其验证功能。
Hibernate validator充其量只能做一个最初步的验证，其功能等同于数据库的表字段的constraint，说实话在实际项目中意义并不大。 我不是指验证复杂的业务规则, 我指的是只是验证数个简单的属性 请 参考一下这篇文章: http://www.matrix.org.cn/resource/article/44/44151_metadata_validation.html 里面提到 matrix 写道 元数据将提供什么？
元数据允许我们绑定框架相关的配置数据到我们的业务对象而无须改变或者继承任何对象固有的职责。我喜欢将元数据跟Javadoc注释做比较。如果你改变了一个Javadoc注释，它并不会改变你的代码的行为的，除非你确实用到Javadoc命令。概念上，元数据以相似的方式运作。你可以把配置数据添加到你的对象，不用改变代码的行为，除非你要寻找该特定的元数据。既然元数据以这样的方式运作，你可以使用标注（Java元数据）来支持持久化，支持你的web应用框架。斟酌这个例子： @Column('usrEmail')@ValidateEmailpublic void setEmail(String email) { this.email = email;} 在上面的例子里，@Column('usrEmail')是一个会在你的持久化框架使用的标注，而@ValidateEmail是在你的web框架里为了验证用户输入使用的。注意到支持这两个框架我们不需要改变setEmail(String)方法，从而保持了它的原汁原味，以及通有的简单性。 在这里我们不要@Column('usrEmail') 也就是我们的表现层和持久化层的对象是分开的不是 一竿子桶到底, 那么我们用来验证Email的合法性不是很好吗 当然 了 该验证在JSF标签中可以已经实现了. 但是如果不用JSF做表现层呢? 上面文中还提到 matrix 写道 路在何方？
像EJB 3.0之类的规范已经增强了元数据对持久化映射的支持了。此外，很多开发人员已经熟悉了XDoclet提供以及使用Javadoc元数据如何对已有框架提供配置细节的了。随着XDclet的流行，使我惊奇的是，在日后发行版本中，框架的开发人员逐渐不再承担提供标注支持了。 就JavaServerFaces而言，John Reynolds最近写了关于验证逻辑改放到何处，以及不赞成当前使用方法的blog。在这篇文章中，为验证框架修改了我们写就的一些代码，你应该结合UIComponent的理念进入到验证处理里。这样就允许了程序员直接在他们的bean里声明验证元数据，而不是分散在JSP页面里。 思索一下，在当今，为了让你的对象在框架里运作需要什么，或者为了迎合你的雇主，你要学习什么API以及规范？XML和Java反射机制是简化我们开发应用和与框架工作方面的一个进步。现在，让我们继续朝着这条路走和以一种认真的看待Java元数据。 |
| 返回顶楼 | |
|
发表时间：2006-01-15
认真看了一下你推荐的文章，这个Hibernate Validator确实有点意思。
在Struts/Spring Web MVC框架中，可以针对ActionForm使用Hibernate Validator，这样可以省却Web框架自己提供的服务器端验证机制，更加简化，不用写一堆验证代码和配置文件了，而且通用性更好。 对于Webwork这样可以直接操作实体类的Web框架来说，用Hibernate Validator多少会带来一些负面影响： 1、性能受影响 假设一个实体类对象是从数据库里面拿出来的，然后在业务层参加运算，并没有接触到Web层，但是每次属性的存取都必须验证一把，虽然未必严重影响性能，但是这样的工作无疑是大大多余的。 2、错误信息不好处理 由于是针对所有实体类的验证，很可能错误信息中夹杂了大量不是当前我们需要验证的类的错误信息 好处也有： 1、比webwork提供的服务器端验证方式简化了很多 2、针对实体类验证会适用范围更大 总体而已，如果采用Webwork，我还是不会用Hibernate Validator，如果是Spring Web MVC或者Struts，到时不错的东西。 BTW:现在Hibernate四处开花了，这可不是什么好现象，Hibernate的核心功能还是有很多不足之处的。 |
| 返回顶楼 | |
|
发表时间：2006-01-15
robbin 写道 认真看了一下你推荐的文章，这个Hibernate Validator确实有点意思。
在Struts/Spring Web MVC框架中，可以针对ActionForm使用Hibernate Validator，这样可以省却Web框架自己提供的服务器端验证机制，更加简化，不用写一堆验证代码和配置文件了，而且通用性更好。 对于Webwork这样可以直接操作实体类的Web框架来说，用Hibernate Validator多少会带来一些负面影响： 1、性能受影响 假设一个实体类对象是从数据库里面拿出来的，然后在业务层参加运算，并没有接触到Web层，但是每次属性的存取都必须验证一把，虽然未必严重影响性能，但是这样的工作无疑是大大多余的。 2、错误信息不好处理 由于是针对所有实体类的验证，很可能错误信息中夹杂了大量不是当前我们需要验证的类的错误信息 好处也有： 1、比webwork提供的服务器端验证方式简化了很多 2、针对实体类验证会适用范围更大 总体而已，如果采用Webwork，我还是不会用Hibernate Validator，如果是Spring Web MVC或者Struts，到时不错的东西。 BTW:现在Hibernate四处开花了，这可不是什么好现象，Hibernate的核心功能还是有很多不足之处的。 没有用过Webwork 在做JSP时 都是用JSF的(以前是JSP) , 毕竟JSF是标准 并且得到了很多大厂的支持, 其他的框架也想了解一下 总是没有时间. 有时间还有看看设计思想吧 . 引用 BTW:现在Hibernate四处开花了，这可不是什么好现象，Hibernate的核心功能还是有很多不足之处的。
是啊 感觉 这个Validator 和 Hibernate core 就每什么关联 单独成为一个项目还差不多 不过好像就太小了 所以 Gavin King 就来了个 Hibernate Validator 怎么用有我们来决定 . ^_^ |
| 返回顶楼 | |
|
发表时间：2006-01-15
我想到了使用Hibernate Validator的一个绝妙场合：
在使用AJAX的分布式调用的时候，是越过Web层直接访问业务层bean的，这个时候我们需要提供业务bean层的Service Facade封装，同时把domain model转换为DTO，而这个DTO是没有任何可用的验证机制的，这个时候Hibernate Validator就可以大显身手了。 |
| 返回顶楼 | |
