詳細講解Hibernate應(yīng)用程序
本文向大家介紹Hibernate應(yīng)用程序，可能好多人還不了解Hibernate應(yīng)用程序，沒有關(guān)系，看完本文你肯定有不少收獲，希望本文能教會你更多東西。
盡管這兩種代碼映射方式都可以使用，不過注釋的優(yōu)勢更為明顯。使用注釋，可以用一些常量來指定長度或其他值。編譯循環(huán)的速度更快，并且不需要生成 XML 文件。其中***的優(yōu)勢是可以訪問一些有用信息，例如運行時的非空注釋或長度。
部分約束如下：
◆@Max(value = 100)
◆@Min(value = 0)
◆@Past
◆@Future
◆@Email
在適當(dāng)條件下，這些注釋會引起由 DDL 生成檢查約束。（顯然，@Future 并不是一個適當(dāng)?shù)臈l件。）還可以根據(jù)需要創(chuàng)建定制約束注釋。
Hibernate應(yīng)用程序
編寫驗證代碼是一個煩人且耗時的過程。通常，很多開發(fā)人員都會放棄在特定的層進行有效性驗證，從而可以節(jié)省一些時間；但是所節(jié)省的時間是否能夠彌補在這個地方因忽略部分功能所引起的缺陷卻非常值得探討。如果在所有應(yīng)用程序?qū)又袆?chuàng)建并維護驗證所需要的時間可以極大地減少，那么爭論的焦點就會轉(zhuǎn)向是否要在多個層次中進行有效性驗證。假設(shè)有一個應(yīng)用程序，它讓用戶使用一個用戶名、密碼和信用卡號來創(chuàng)建一個帳號。在這個Hibernate應(yīng)用程序中所希望進行驗證的組件如下：
◆視圖：通過 JavaScript 進行驗證可以避免與服務(wù)器反復(fù)進行交互，這樣可以提供更好的用戶體驗。用戶可以禁用 JavaScript，因此這個層次的驗證***要有，但是卻并不可靠。對所需要的域進行簡單的驗證是必須的。
◆控制器：驗證必須在服務(wù)器端的邏輯中進行處理。這個層次中的代碼可以以適合某個特定用途的方式處理驗證。例如，在添加新用戶時，控制器可以在進行處理之前檢查指定的用戶名是否已經(jīng)存在。
◆服務(wù)：相對復(fù)雜的業(yè)務(wù)邏輯驗證通常都最適合放到服務(wù)層中。例如，一旦有一個信用卡對象看起來有效，就應(yīng)該使用信用卡處理服務(wù)對這個信用卡的信息進行確認(rèn)。
◆DAO：在數(shù)據(jù)到達這個層次時，應(yīng)該已經(jīng)是有效的了。盡管如此，執(zhí)行一次快速檢查從而確保所需要的域都非空并且值也都在特定的范圍或遵循特定的格式（例如 e-mail 地址域就應(yīng)該包含一個有效的 e-mail 地址）也是非常有益的。在此處捕獲錯誤總比產(chǎn)生可以避免的 SQLException 錯誤要好。
◆DBMS：這是通?？梢院雎则炞C的地方。即使當(dāng)前正在構(gòu)建的應(yīng)用程序是數(shù)據(jù)庫的惟一客戶機，將來還可能會添加其他客戶機。如果應(yīng)用程序有一些 bug（大部分應(yīng)用程序都可能會有 bug），那么無效的數(shù)據(jù)也可能會被發(fā)送給數(shù)據(jù)庫。在這種情況中，如果走運，就可以找到無效的數(shù)據(jù)，并且需要分析這些數(shù)據(jù)是否可以清除，以及如何清除。
◆模型：這是進行驗證的一個理想地方，它不需要訪問外部服務(wù)，也不需要了解持久性數(shù)據(jù)。例如，某業(yè)務(wù)邏輯可能會要求用戶至少提供一個聯(lián)系信息，這可以是一個電話號碼也可以是一個 e-mail 地址；可以使用模型層的驗證來確保用戶的確提供了這種信息。
【編輯推薦】
