本文向大家介紹Hibernate應用程序可能好多人還不了解Hibernate應用程序沒有關系看完本文你肯定有不少收獲希望本文能教會你更多東西
盡管這兩種代碼映射方式都可以使用不過注釋的優勢更為明顯使用注釋可以用一些常量來指定長度或其他值編譯循環的速度更快並且不需要生成 XML 文件其中最大的優勢是可以訪問一些有用信息例如運行時的非空注釋或長度
部分約束如下
◆@Max(value = )
◆@Min(value = )
◆@Past
◆@Future
◆@Email
在適當條件下這些注釋會引起由 DDL 生成檢查約束（顯然@Future 並不是一個適當的條件）還可以根據需要創建定制約束注釋
Hibernate應用程序
編寫驗證代碼是一個煩人且耗時的過程通常很多開發人員都會放棄在特定的層進行有效性驗證從而可以節省一些時間但是所節省的時間是否能夠彌補在這個地方因忽略部分功能所引起的缺陷卻非常值得探討如果在所有應用程序層中創建並維護驗證所需要的時間可以極大地減少那麼爭論的焦點就會轉向是否要在多個層次中進行有效性驗證假設有一個應用程序它讓用戶使用一個用戶名密碼和信用卡號來創建一個帳號在這個Hibernate應用程序中所希望進行驗證的組件如下
◆視圖通過 JavaScript 進行驗證可以避免與服務器反復進行交互這樣可以提供更好的用戶體驗用戶可以禁用 JavaScript因此這個層次的驗證最好要有但是卻並不可靠對所需要的域進行簡單的驗證是必須的
◆控制器驗證必須在服務器端的邏輯中進行處理這個層次中的代碼可以以適合某個特定用途的方式處理驗證例如在添加新用戶時控制器可以在進行處理之前檢查指定的用戶名是否已經存在
◆服務相對復雜的業務邏輯驗證通常都最適合放到服務層中例如一旦有一個信用卡對象看起來有效就應該使用信用卡處理服務對這個信用卡的信息進行確認
◆DAO在數據到達這個層次時應該已經是有效的了盡管如此執行一次快速檢查從而確保所需要的域都非空並且值也都在特定的范圍或遵循特定的格式（例如 email 地址域就應該包含一個有效的 email 地址）也是非常有益的在此處捕獲錯誤總比產生可以避免的 SQLException 錯誤要好
◆DBMS這是通常可以忽略驗證的地方即使當前正在構建的應用程序是數據庫的惟一客戶機將來還可能會添加其他客戶機如果應用程序有一些 bug（大部分應用程序都可能會有 bug）那麼無效的數據也可能會被發送給數據庫在這種情況中如果走運就可以找到無效的數據並且需要分析這些數據是否可以清除以及如何清除
◆模型這是進行驗證的一個理想地方它不需要訪問外部服務也不需要了解持久性數據例如某業務邏輯可能會要求用戶至少提供一個聯系信息這可以是一個電話號碼也可以是一個 email 地址可以使用模型層的驗證來確保用戶的確提供了這種信息
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28259.html
