EJB中資料驗證出現在什麼地方最合適(轉載) (轉)

EJB中資料驗證出現在什麼地方最合適(轉載) (轉)[@more@]中資料驗證出現在什麼地方最合適
 
 我們將討論資料驗證邏輯應該出現在 EJB 應用程式碼的什麼位置，而不是專注於驗證過程（ 技術專區的其它地方對此進行了很好的討論）。在本系列先前的技巧文章中，我們瞭解了很多組成基於 EJB 技術的應用程式的：底層會話 bean 及其業務介面；在實體 bean 及其客戶機之間傳送資料的值以及擔任  層和業務層之間的保護層的各種委派類。驗證邏輯十分適合這些元件中的任何一個。實際上，您可以在多個元件中放置驗證邏輯，在整個應用程式中分層次地放置它（儘管這樣做是不可取的）。因此，我們在此處提出的問題是：在 EJB 應用程式的什麼位置放置驗證程式碼最有利？

資料驗證的型別
 要確定將驗證程式碼放置在什麼位置，第一步是瞭解您正在處理什麼型別的驗證。資料格式驗證確保所有資料型別（整數、浮點數、字串等）都是正確的。它還要確認變數都在允許值的範圍之內以及實際的按預期的匹配。本質上，資料格式驗證處理驗證的任何方面，這些驗證不需要應用特定業務規則

特定於業務的驗證基於一組業務規則（例如，確保所提供的 ISBN 號與您中的實際書籍相匹配）。它幾乎總是需要對 EJB 層以及應用程式中的其它業務邏輯元件具有訪問權。

資料格式驗證
 確定了正在處理的驗證型別之後，下一步是確定放置程式碼的位置。在您的 EJB 應用程式中，資料格式驗證邏輯可以如下進行放置：

將賦值（setter）方法放置在業務委派上。 
將賦值（setter）方法放置在 bean 的介面上。 
將賦值（setter）方法放置在 bean 的訊息物件或值物件上。 
對於本示例，我們將假定您正在處理一個包括業務委派的 EJB 應用程式。如果是這樣，那麼您應該採取某些步驟，確保所有的應用程式客戶機（處於 Web 層）都在使用委派進行 bean 訪問，而不是直接訪問 bean。如果確實是這樣，那麼您可以將所有資料驗證程式碼都地放置在業務委派方法中，如清單 1 所示。

清單 1. 業務委派中的資料格式驗證 package com.ibm.library;

import java..RemoteException;
import java.util.Iterator;
import java.util.List;
import javax.ejb.CreateException;
import javax.naming.NamingException;

public class LibraryDelegate implements ILibrary {

 private ILibrary library;

 public LibraryDelegate() {
 init();
 }

 public void init() {
 // Look up and obtain our session bean
 try {
 LibraryHome libraryHome =
 (LibraryHome)EJBHomeFactory.getInstance().lookup(
 "java:comp/env/ejb/LibraryHome", LibraryHome.class);
 library = libraryHome.create();
 } catch (NamingException e) {
 throw new RuntimeException(e);
 } catch (CreateException e) {
 throw new RuntimeException(e);
 } catch (RemoteException e) {
 throw new RuntimeException(e);
 }
 }

 // No validation required for accessor (getter) methods

 public boolean checkout(Book book) throws ApplicationException {
 // No validation required here; the  type
 // takes care of it

 try {
 return library.checkout(book);
 } catch (RemoteException e) {
 throw new ApplicationException(e);
 }
 }

 public boolean checkout(List books) throws ApplicationException {
 // Validate list
 for (Iterator i = books.iterator(); i.hasNext(); ) {
 Object obj = i.next();
 if !(obj instanceof Book) {
 throw new ApplicationException(
 ApplicationException.VALIDATION_ERROR,
 "Only Books are allowed in the input list");
 }
 }

 try {
 return library.checkout(books);
 } catch (RemoteException e) {
 throw new ApplicationException(e);
 }
 }

 // And so on...

 public void destroy() {
 // In this case, do nothing
 }
}


 

 對於資料格式驗證，您希望使驗證邏輯儘可能靠近客戶機。資料格式驗證經常觸發錯誤頁面或要求客戶機重新輸入格式錯誤的資料。在這些情況下，您希望花費最少的處理開銷迅速向客戶機提供反饋。透過將驗證邏輯放置在業務委派中，您已經建立了最自然的錯誤處理方案。當客戶機嘗試向委派查詢帶有格式錯誤的資料時，就會觸發錯誤，請求被直接送回客戶機，並就該問題警告。

 將驗證邏輯放置在 bean 實現中會導致低的驗證過程。錯誤訊息將從 bean 實現傳送到委派，而不是直接從委派傳送到客戶機，這很象 RemoteException，而不象應用程式異常。除了遠端異常的代價之外，委派還將付出 JNDI 查詢、RMI 流量以及（可能有）額外的業務邏輯的代價 — 花費在單個驗證錯誤上的力氣太多了！

特定於業務的驗證
 特定於業務的驗證完全是一種不同的情形。業務驗證錯誤通常比資料驗證錯誤更復雜，並很少透過客戶機互動獲得解決。解決特定於業務的錯誤要求使用額外的實體和會話 bean 以及資料庫訪問，這些都必須透過 JNDI 和 RMI 事務進行處理。把這種驗證放在業務委派上花費的開銷會很大。更好的主意是將這種驗證移回 EJB 層，尤其是放置到 bean 的實現類中。

 在將該驗證放置在應用程式的這一層時，所有 RMI 流量都應該是本地的；大多數應用程式都將使用 VM 內的，以使 bean-到-bean 互動速度極快。您也可以避免 JNDI 訪問，因為許多 bean 已經查詢了相關 bean 的主（home）介面。此外，您的業務委派已經處理了所有必要的資料格式驗證。

結束語
在決定將驗證程式碼放置在哪裡時，很重要的是能夠分辨兩種驗證型別。資料驗證是比業務驗證簡單得多的驗證型別，一般的是使它儘可能靠近客戶機。特定於業務的驗證更復雜，並通常需要幾種不同的事務來完成。這類驗證應該放在 EJB 層，在那裡，它可以儘可能地利用現有的程式。