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