在圖表6的設計中，表示層不通過facade而直接調用域對象，Spring AOP仍然提供服務，例如事務處理管理和安全。
用這種實現途徑的一個重要的好處是，業務層不需要知道哪些對象需要調用，也不用知道那些需要返回給表示層。盡管這挺起來很簡單，但是你會發現一些缺點。這會增加表示層的復雜度，因為你必須處理對數據庫的連接。而且在基于Web的應用程序中，事務處理管理也要非常小心，因為在表示層將數據反饋給瀏覽器之前，事務處理的數據必須保持正確。
決策3：訪問數據庫
無論你怎樣對業務邏輯怎樣的組織和封裝，最終你還是要從數據庫中取數據出來。在經典的J2EE應用程序中，你有2個選擇：JDBC——這個需要很多的底層代碼;或者實體Bean——這個用起來非常困難，而且缺少重要特征。相比來說，使用輕量級構架令人高興的事情之一就是：你有一些新的而且更有力的方法去訪問數據庫，而且這種方法可以顯著的減少訪問數據庫的代碼。讓咱們來進一步研究。
直接用JDBC會有什么問題
最近突然出現了對象/關系 映射構架(比如JDO和Hibernate) 和SQL映射構架(比如iBATIS)這些不是憑空出現的。相反，他們是在JAVA 聯盟在JDBC屢造挫折之后才出現的。為了了解新構架出現的原因，這里咱們回顧一下直接使用JDBC會出現的問題。在許多程序中直接使用JDBC不是一個好的選擇，主要有以下三個原因：。 開發和維護SQL非常的困難而且耗費時間——一些開發者發現要寫龐大而且復雜的SQL語句非常的困難。反映數據庫變化的SQL語句會變得非常耗時。你必須小心的考慮犧牲可維護性是否值得。。 用SQL會使移植性變的很差——因為需要數據庫的特殊SQL語句。如果一個程序和多個數據庫有關系，那么你就要寫多個版本的SQL語句，這使得可維護性變變成噩夢。。 直接寫JDBC代碼要會非常耗時，而且容易出錯。你必須寫很多的樣板代碼去獲得連接，創建和初始化適當的聲明，還要用精確的聲明去清理連接。而且你還要寫代碼去將JAVA 對象映射到SQL聲明。由于要無奈的去寫，JDBC代碼很容易出錯。
如果你的程序必須直接運行SQL語句的話，那前面兩個問題是無法避免的。有時候為了獲得好的性能，必須要全力的寫SQL語句，包括供應商提供的那些特殊東西。由于許多業務上的原因，持久層可能會產生混亂的SQL語句，為了防止這種情況，DBA可能要求你的程序來完全控制SQL語句的執行。通常，團隊買進的關系型數據庫過于龐大，以至于應用程序工作時會出現一些和數據庫有關的瑣碎事務。根據“iBATIS in Action”的作者說這里會有一種情況出現：“數據庫或者SQL語句本身存在的時間比程序代碼存在的時間還要長，或者同一段SQL語句或數據庫有多個程序的版本。有些情況下，程序已經用另外一種語言重寫了，但是SQL語句和數據庫卻沒有太大的改變�！� 如果直接使用SQL弄的你筋疲力盡，那么很幸運，這里有一種直接執行SQL語句的構架，它可比用JDBC要容易多了。當然了，這就是iBATIS.
使用iBATIS
我開發過的所有企業JAVA應用程序，都是直接執行SQL語句的。早期的程序是執行特定的SQL語句的，后來是用持久層構架再用少量的SQL語句構成的。一開始我直接用JDBC來執行SQL語句，但是后來，我經常寫一些小的構架去完成JDBC中那些比較無聊的部分。我也用過一段Spring的JDBC類，這些類除去了JDBC中的許多樣板代碼。但是無論是我自己寫的構架還是使用Spring的類，在Java類映射到SQL語句的時候都會存在問題，這就是我為什么那么高興的加入iTATIS 那邊的原因了。
iBATIS 不僅將應用程序完全的與“數據庫連接”、具體的SQL語句隔絕開來，更實現了通過XML描述文檔來將JavaBean 映射到SQL語句。它用Java bean 內省機制來將“道具bean(bean properties)”映射為相應的數據庫語句占位符，而且它可以將ResultSet后的結果構造為bean.它還可以通過數據庫生成主鍵，自動加載相關的對象、實現緩存和lazy loading.這樣，iBATIS 就除去了許多執行SQL語句帶來的苦差。通過編輯XML描述文檔和調用少量的iBATIS的API，代替了寫大量的JDBC底層代碼。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
