本文向大家介绍Hibernate应用程序可能好多人还不了解Hibernate应用程序没有关系看完本文你肯定有不少收获希望本文能教会你更多东西
尽管这两种代码映射方式都可以使用不过注释的优势更为明显使用注释可以用一些常量来指定长度或其他值编译循环的速度更快并且不需要生成 XML 文件其中最大的优势是可以访问一些有用信息例如运行时的非空注释或长度
部分约束如下◆@Max(value = )
◆@Min(value = )
◆@Past
◆@Future
◆@Email
在适当条件下这些注释会引起由 DDL 生成检查约束（显然@Future 并不是一个适当的条件）还可以根据需要创建定制约束注释
Hibernate应用程序
编写验证代码是一个烦人且耗时的过程通常很多开发人员都会放弃在特定的层进行有效性验证从而可以节省一些时间但是所节省的时间是否能够弥补在这个地方因忽略部分功能所引起的缺陷却非常值得探讨如果在所有应用程序层中创建并维护验证所需要的时间可以极大地减少那么争论的焦点就会转向是否要在多个层次中进行有效性验证假设有一个应用程序它让用户使用一个用户名密码和信用卡号来创建一个帐号在这个Hibernate应用程序中所希望进行验证的组件如下
◆视图通过 JavaScript 进行验证可以避免与服务器反复进行交互这样可以提供更好的用户体验用户可以禁用 JavaScript因此这个层次的验证最好要有但是却并不可靠对所需要的域进行简单的验证是必须的
◆控制器验证必须在服务器端的逻辑中进行处理这个层次中的代码可以以适合某个特定用途的方式处理验证例如在添加新用户时控制器可以在进行处理之前检查指定的用户名是否已经存在
◆服务相对复杂的业务逻辑验证通常都最适合放到服务层中例如一旦有一个信用卡对象看起来有效就应该使用信用卡处理服务对这个信用卡的信息进行确认
◆DAO在数据到达这个层次时应该已经是有效的了尽管如此执行一次快速检查从而确保所需要的域都非空并且值也都在特定的范围或遵循特定的格式（例如 email 地址域就应该包含一个有效的 email 地址）也是非常有益的在此处捕获错误总比产生可以避免的 SQLException 错误要好
◆DBMS这是通常可以忽略验证的地方即使当前正在构建的应用程序是数据库的惟一客户机将来还可能会添加其他客户机如果应用程序有一些 bug（大部分应用程序都可能会有 bug）那么无效的数据也可能会被发送给数据库在这种情况中如果走运就可以找到无效的数据并且需要分析这些数据是否可以清除以及如何清除
◆模型这是进行验证的一个理想地方它不需要访问外部服务也不需要了解持久性数据例如某业务逻辑可能会要求用户至少提供一个联系信息这可以是一个电话号码也可以是一个 email 地址可以使用模型层的验证来确保用户的确提供了这种信息
