詳細講解Hibernate應用程序
本文向大家介紹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 地址；可以使用模型層的驗證來確保用戶的確提供了這種信息。
【編輯推薦】
