http://dev2dev.bea.com.cn/bbs/jishudata/ArticleShow.jsp?Id=15
作者：zhoubikui(dev2dev ID)
摘要：
希望本文能引起各位J2EE開發同行的激烈爭論。EJB是J2EE的全部嗎？被偷走的EJB該如何回來？本文結合自己最近在WEBLOGIC的開發的J2EE項目的得與失和最新的J2EE發展技術嘗試一種新的J2EE解決方案。最后用DEMO小試牛刀，希望能得到答案和啟迪。
目錄：
一、背景：
二、開發環境
三、系統開發框架
3.1該開發模型的特點
3.2 層與層之間數據交互XML Data Bus
3.3 數據持久層設計
四、反思
4.1該模式的優點
4.2借鑒
4.3反思
五、較理想的J2EE解決方案
5.1 J2EE分層
5.2設計目標
5.3 J2EE數據持久層開發
5.4業務邏輯層的設計
5.5 業務層和數據持久層數據總線
六、實踐
6.1開發思路
6.2系統設計
6.2.1總體設計
6.2.2 數據持久層設計
6.2.3 業務邏輯層設計
6.2.4 WEB層設計
6.2.5 總 結
6.3源碼下載
七、BEA能為我們做更多
八、總結
相關資源下載
參考資料
一、背景：(目錄)
J2EE是開發企業很好的平臺。它內涵非常豐富，使用人群也非常龐大，有很多最佳實踐經驗和優秀工具。事實證明,J2EE確實可以為復雜的企業應用提供強大的技術保障。但由于它過于復雜，開發人員缺乏足夠技巧和開發經驗，往往也是導致J2EE項目落馬的原因。
這個題目可能會讓您覺得有些嘩眾起寵的味道，但這個在J2EE潛水的小蝦米如果能讓您對目前的開發哪怕有一點小的觸動就很滿足了。我寫這篇文章時已經穿好了防彈衣，期待著您的西紅柿和鮮花!
看了一些論壇里的帖子，讓我很疑惑的是為什么EJB看來是如此的成功?但我卻發現在 本公司和其它競爭對手以及我兄弟們中的牛公司中使用EJB的是少之又少。
疑惑!誰動了我的EJB？
Bea的 WebLogic是如此的出色，以至于WebLogic 8出來后 我們這些日日夜夜的不停推磨的驢子簡直都可以洗洗睡了。
但具有諷刺意味的是倘若你問我們為什么要買WebLogic，因為sun的 iplanet不停的掛掉，我們終于受不了，也不敢再相信sun one server。選擇WebLogic因為我們需要一個可靠的web server支持jsp罷了。
首先說明我不是EJB的反對者，我依然希望EJB能在數據持久層開發中發揮重要作用。我將在正文中講我的想法，我想BEA的WebLogic可以帶給我們更多好的東西。
二、開發環境 (目錄)
> 操作系統：WINDOWS 2000
> J2EE應用程序服務器：BEA WEBLOGIC SERVER 6.1
> 開發工具：EOS studio33 （其實就是對WEBLOGIC studio的改造加入了一些財政開發常用的庫讓業務流程能象工作流的開發），DEMO例子都是在eclipse下開發的與這開發工具無關。
> 數據庫：ORACLE 9I
三、系統開發框架(目錄)
下面是我們公司和XXX一塊合作開發的一套國庫縣鄉系統，為了提高開發效率我們對WebLogic 6 的STUDIO開發工具作了一些改造，加入了我們的構件庫。使業務能圖形化開發的嘗試，有點類似現在WebLogic 8的工作流的開發。這是一次不太成功的試驗，但確實能帶給我們一些新的東西。由于大多數用戶沒有相同的開發環境，我不打算對技術細節做太多描述，只寫對現在J2EE開發框架有沖擊的東東。
我們將企業系統可以劃分為頁面層、業務流程層、服務層、對象層和數據層五個層次。從實現各層的技術標準看，頁面層技術有JSP及portal等，業務流程技術有WfMC及BPML等，服務層技術有EJB及Web Services、對象技術有JDBC、XML，數據技術有各類數據庫產品，如：DB2、Oracle、SQL Server，以及SQL92等相關標準。
圖一
該系統就是在這些技術標準基礎上，對各技術層次上的業務內容實現了面向構件的封裝。構件的最終實現技術仍為各層次的標準技術。將頁面層業務內容封裝為頁面構件及頁面模版構件，將流程業務內容封裝為工作流程圖和頁面流程構件，將服務業務內容封裝為業務邏輯構件；將對象封裝為運算邏輯等基礎構件，將數據封裝為數據構件。
3.1該開發模型的特點(目錄)
（1） 從系統框架層次看，它是一個標準的MVC系統框架，是當前主流的、公認的系統框架。
（2） 在應用系統中，業務構件在運行時的表現為標準的EJB。在運行系統中，構件接口形式、互操作形式完全使用EJB標準。
（3） 基礎構件都是完全符合J2EE技術標準的，包括JDBC、JMS、JSP、JNDI技術等。這些技術標準的采用使開發的應用系統成為完全符合J2EE標準的應用系統。
（4） 在系統配置、數據接口、內存數據管理各方面采用了XML技術標準。由于XML具有良好的自描述性和順序無關性，利用XML標準進行數據交換、內存數據管理使系統具有更加良好的可擴展性和伸縮性。基于該開發的應用系統是一個符合XML標準的應用系統。
在面向構件和可視化的構件組裝過程中，同樣采用了XML的定義格式，使構件的組裝基于XML而非代碼層定義，并在應用裝載時由運行支撐環境解釋為標準的J2EE。這即保證了此應用系統自身的簡潔性，又保持了應用系統的標準性。
3.2 層與層之間數據交互XML Data Bus(目錄)
層間上下可互訪，但不能越過相鄰層通訊。層間數據交互用XML作為交互載體。見下圖。
圖二
3.3 數據持久層設計(目錄)
普通的J2EE平臺都不提供相關的建模與數據管理工具，而采用專用工具（如：PowerDesigner 或 Rational Rose等），這增加了多個工具間的切換和使用復雜度；另外，由于數據模型工具對是多個、異構數據庫系統支持的簡單性，使程序員常常需要在這些工具之外進行許多的代碼編寫工作。
它提供了專用數據模型工具（Database Designer Tools）對應用模型設計、模型管理、數據結構生成進行一體化的處理。同時，由于其工具內部內置了數據映射功能，使數據結構面對多樣、異構的數據庫（如:Oracle、DB2、MSSQL等）時，可以以統一的調用和對前臺無影響的系統數據移植方式為前臺應用提供服務。
圖三
四、反思(目錄)
看了這么多花花綠綠的圖片和理論，可能把您的頭都搞大了。下面匯總一下前面的內容。
4.1該模式的優點(目錄)
> 嚴格分層，為了實現層的修改不會影響相關層的。系統采用了顯示層，展現層、業務流程層、服務層、對象層和數據層六層結構。
> 層與層之間數據交互采用XML Data Bus，這樣基本上實現層中修改不會影響上下兩層，最多是利用映射，服務器重起一下。
> 這種模塊化有利于分層開發相對的控件和圖形化開發工具。
> 最令人心動的是專用數據模型工具（Database Designer Tools），只需配一下數據庫連接就可以實現得到表的增刪改查。
> 最讓人感動的是處處用到EJB技術，可使用者從來沒感覺到使用了某種特定技術，只是簡單調用數據持久層的增刪改查方法就OK了！
4.2借鑒(目錄)
多么美的事情，我當初看到真是一夜未眠，最終也為后來項目不太成功打下伏筆。現在分析起來主要是：
XML Data Bus設計有問題，由于XML在HTTP中傳數據有自身的弱點，如XML會把XML空格結點去掉，結果頁面有個TEXT顯示數據庫某個字段aa的值test,我想把它賦空，在頁面到展現層時XML自動忽略這個結點，最后數據庫更新可想而知，我依然是我。
開發工具不穩定，某些技術不太成熟，也沒有較好的編輯工具，修改一個小東西，簡直有點大海撈針的味道非常考驗人的耐性，開發前期很順，到了后期，服務器無名火到處發，現象重現率也不高，系統正常都不知怎么正常的，維護簡直是噩夢。
簡單是我們程序開發中一個很重要的原則，簡單會減少我們出錯的概率，而且即使出現錯誤也能很快糾正。
4.3反思(目錄)
雖然有這樣或那樣的失敗原因，但憑心而論，這套J2EE解決方案確實還是有其獨特的魅力。
我的體會主要有這樣的幾點：
> J2EE開發肯定需要分層，但不宜分層太多。MVC的方式比較好。從開發和維護角度考慮，分四層結構比較合適。
圖四
> 數據持久層好寫但不容易寫好，這是系統最基礎也是最核心的部件，一個程序的好壞很大關系是它決定的。EJB想說愛你真的不容易，O/R面向對象的數據庫編程對一些簡單的業務操作能提升很大的開發效率，可惜我們的數據庫很復雜，簡單說說我們的權限判斷，嚴肅到數據庫表的哪個字段用戶當前職責是可讀還是可寫，而且這些關系大量SQL執行找到最接近的數據訪問權限，我想目前除了IBATIS勉強滿足外，Hibernate敢都不敢想。非常希望BEA的WEBLOGIC能開發類似EOS的專用數據模型工具（Database Designer Tools），不要讓我知道我在用什么技術調用數據庫，我只用告訴它需要對數據庫做什么操作就行，最好能像MS的工具箱一樣，給個控件告訴它對應什么表，該做什么操作，以及該操作需要什么前提條件。條件只是按它映射命名的對象就可以自動組合合適的SQL或采用相應的EJB操作。我們真得不想關心，你是用JDBC還是EJB實現的，我們只需要最佳的效果，這個WEBLGIC完全可能根據當前SERVER容器的支持環境做出。
> 層與層間數據傳遞用VO對象，也可用串行化實現。
> MVC中M的開發業務層和數據層組織形式采用DAO模式比較好。事務放在業務層，采用J2EE容器的事務聲明方式。
可能這些想法并沒太多新鮮的成分，但我需要強調的是數據持久層的設計應該有構件化的產品，開發人員不需要了解如何得到是通過EJB或是JDBC從數據庫中得到數據，WEB SERVER容器中提供什么服務，它可以自動選擇方式，當然也可手工設置。
這個問題是可以得到很好解決的，注意我DAO的設計思想，數據持久層不需要考慮事務等一些復雜的問題，它只需簡單對表做增刪改查的工作。
開發人員需要做的是二件事
> 開發人員配置數據庫連接，工具能自動建立表與數據持久層對象的映射
> 開發人員利用構件化的工具包（屬性包含數據持久層對象名和調用條件（VO對象），方法有增刪改查）簡單配置，然后裝配到業務層就能實現業務邏輯的演練。
這個開發需要注意它是個獨立的層，不會依賴某一數據庫或WEB SERVER容器，是個通用的數據持久層的解決方案。我相信BEA公司會把這種設想做得更好！
開發人員需要數據持久層開發效率和性能，我們再使用EJB，但不需要過多陷于EJB中。
五、較理想的J2EE解決方案(目錄)
5.1 J2EE分層(目錄)
涉及到的java類可以分為這么幾種：
> VO/command類。
用于各層之間傳輸數據用。只有set,get方法。值對象盡量要通用性強。屬性方法多。
> controller類
用于處理用戶提交請求。建議將多個有緊密關系的功能點放在一個類里。如對計劃的瀏覽，提交，修改，就可以放在一個類里。Controller類負責前臺的，不重要的數據校驗。并調用fa?ade類完成業務。
> fa?ade類
管理類或者門面類。一個模塊只能有一個這樣的類，所有的controller類都調用該類，而不直接調用DAO類。該類里面起事務處理，本身沒有功能，調用DAO類完成功能。
> DAO類
負責具體的數據庫存取操作。原則上一個表對應一個DAO類，也可以按對象來建立類。
這個MVC開發方式本身可能沒有太多新鮮的地方，其相同點在這里就不說了，本文具體就怎樣構件M？也就是業務邏輯層和數據持久層的架構。
5.2設計目標(目錄)
充分利用OOP設計的優勢
避免了不必要的復雜
具有可維護性、可擴展性
避免任何特定平臺或非標準化
不重新開發已有的東西目前Spring的Ioc模式實現的BeanFactory和AOP，編制程序時，只要寫被調用者的接口代碼，具體子類實例可通過配置實現，它不依賴特定平臺，你可一全部用它的框架，也可以只用其中一部分。
這種新的架構出現，使我覺得以下情況實現成為可能！
數據持久層設計圖形化構件化開發能成為可能，它只管和數據庫數據交互更新，不要擔當太多的責任。而業務邏輯層自我定制構件將會變得非常簡單，而且借鑒J2EE的EJB事務容器申明也得到解決。業務邏輯層實現有點象小時侯搭積木一樣輕松的把數據持久層構件組合就能實現。下面將就數據持久層構件化和業務邏輯層分別論述。
5.3 J2EE數據持久層開發(目錄)
數據持久層設計構件化開發可能？
數據持久層設計目標：
操作簡單，我們希望只需將數據連接配置好，然后我們將構件與數據庫具體表對應上，接下來告示它操作類型，傳入條件參數（VO類）后，余下的任務全有他完成。數據持久層只管和數據庫數據交互更新，本身只對表的增刪改查的動作，非常簡潔，硬編碼也不會太復雜。
調用只需要利用Spring的BeanFactory簡單配置，就可在業務處理層直接調用。這個過程只是簡單改寫一下配置文件，其圖形化，非常容易實現。
測試，我們在數據持久層用的是接口編程模式，利用JUIT或Spring本身資源讀取API很容易寫測試方法。
維護和修改很方便。由于是具體子類實例可通過配置實現，非常方便修改和擴展。
目前有一些類似產品，可惜都是依賴某一特定平臺或技術，你要么全部按他的規范做，要么全部放棄。它使你在某一方面方便的卻在另外方面限制你，讓你沒法施展拳腳。
當前比較恰當的組合Spring的BeanFactory+IBATIS，能較好滿足輕量級系統的開發。我希望BEA公司的WEBLOCIC能在這方面為我們提供精彩的解決方案。
借鑒Spring的BeanFactory和AOP技術和BEA在EJB的造詣，BEA完全可能把它做得更好！而且基于以上分析，技術難度上不會太大。我們有理由期待數據持久層設計構件化圖形化的到來。我覺得它的出現應該除了前面的特點，還應有下面的特點：
開發者，不需要知道數據持久層是用EJB或是JDBC實現的具體細節。該構件能自動根據服務容器的支持，選擇是EJB或是JDBC實現。
EJB本身沒有錯，錯在它能力太多，讓使用者無法駕御。我們開發人員關注的是數據持久層的本身功用和性能，我們不管你是用EJB或是JDBC實現的。我們需要簡單持久性能優良的解決方案。請不要讓EJB做太多的實質是數據持久層不要做太多。
5.4業務邏輯層的設計(目錄)
面向接口的開發，它具有很強的靈活度和擴展性。
業務邏輯層調用也用Spring的BeanFactory組合，這樣在數據持久層設計構件化的同時，我們業務邏輯層自我定制構件將會變得非常簡單。
我們將數據持久層中的事務處理提到業務邏輯層的理由是不用多說的。我們只需簡單對SPRING的bean管理的配置文件增加攔截代理對象，為了給業務邏輯對象增加事務處理。其簡單聲明如下：
<!-- Transaction manager for a single JDBC DataSource -->
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource"><ref local="dataSource"/></property>
</bean>
<bean id="systemManager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager"><ref local="transactionManager"/></property>
<property name="target"><ref bean="業務邏輯"/></property>
<property name="transactionAttributes">
<props>
<prop key="query*">PROPAGATION_SUPPORTS,readOnly</prop>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
transactionAttributes屬性可以設置事務處理的方式，事務隔離級別，是否只讀三個屬性，用逗號隔開。事務隔離級別各數據庫系統不完全支持，一般不設置，用默認的即可。
事務處理選項有如下幾個：（前面2個常用）
PROPAGATION_REQUIRED － 需要事務處理。如果當前不存在事務環境，則創建一個；
PROPAGATION_SUPPORTS － 如果當前存在事務環境，則作為其中的一部分。如果不存在，則按非事務方式執行；
PROPAGATION_REQUIRES_NEW － 需要事務處理。并總是開啟一個新事務。如果已經存在事務環境，則掛起之；
PROPAGATION_MANDATORY － 執行到指定方法時，必須已經存在事務環境，否則出錯；
PROPAGATION_NEVER － 不支持事務操作，如果存在事務環境會出錯；
PROPAGATION_NOT_SUPPORTED － 不支持事務操作。如果存在事務，則掛起。 如果要追求好的性能，我們可以在此定義事務精確到到某一方法的某一異常起事務回滾。
WEBLOGIC SERVER可以協調涉及多個資源的事務時，JTA的許多高級事務協調特性才能發揮。對一個跨數據庫資源的事務，將采用兩個階段提交（Two-Phase Common,2PC）技術處理。實際上對用戶而言2PC技術是透明的。在應用JTA驅動程序時，需要連接多個資源，指定針對這些資源的操作等。只要XA兼容，WEBLOGIC就會把這些資源集成到一個事務中，使所有的資源相互協調一致工作，或者都成功或者都失敗。TXDATASOURCE建立與多個XA兼容資源之間的橋實現。JAT負責處理JTA事務與底層資源的相互協調。
要實現這種功能只需將<bean id= transactionManager >換成如下寫法就可：
<bean id=” transactionManager”class=”org.springframework.transaction.jta.JtaTransactionManager”/>
5.5 業務層和數據持久層數據總線(目錄)
業務層和數據持久層交互為何采用VO對象而不是XML或SQL字符串作為傳遞參數？
①前者分層明晰，后者把SQL生成放在業務層，在業務類中硬編碼SQL，導致代碼難于維護和擴展SQL代碼到處出現在你的類代碼中。這樣的好處是寫代碼效率很高，對于小型應用程序或者原型，這樣是可行的。缺點是直接耦合了你的業務類與關系數據庫結構。業務層不應該做數據層的工作。而且業務層或數據庫字段變動，會引起兩層修改。維護不方便，也不利于數據持久層的接口抽象。
②前者更加符合面向對象的開發思想。面向對象應用程序可以使用關系數據庫作為持久機制而不需要在程序中使用嵌入SQL。后者沒有仔細考慮對持久機制維護和管理的應用程序帶來的繼承脆弱性。
③前者增加VO對象時，業務和數據持久層代碼幾乎不需任何修改。可理解性和兼容性都比后者好。
六、實踐(目錄)
前面說了不少理論的東東，大家可能都有點厭倦了，下面通過一個實例解釋一下。限于篇幅，我將項目中常用的分頁實現作為例子給大家說說。由于目前數據持久層還沒有比較好的構件化開發工具，現用IBATIS代替。大部分內容都不會講太細的細節，因為我假定讀者有SPRING和IBATIS的基礎知識。限于篇幅，我們重點放在業務邏輯和數據持久層的實現上，詳細內容見源碼，有比較詳細的解釋。
6.1開發思路(目錄)
分頁邏輯：頁面需要保存以下參數：
總行數：根據sql語句得到總行數 每頁顯示行數：設定值pageSize 當前頁數：請求參數page
頁面根據當前頁數和每頁行數計算出當前頁第一行行數，定位結果集到此行，對結果集取出每頁顯示行數的行即可。
在SESSION存放數據列表是這么考慮的：對于大量數據，比如10000條，肯定不能一次全取出來。通常是每次取一頁的數據，如20條，其實效率也不高。 最好是每次取出來(比如)10頁的數據，放在session里。這樣，翻10頁才會查一次數據庫。
圖五
6.2系統設計(目錄)
6.2.1總體設計(目錄)
后臺數據持久層，采用DAO模式；中間邏輯層，采用Facade模式；前端Web層，采用MVC結構，使用JSP作為視圖。其組裝詳見下圖：
圖六
利用Spring的Ioc模式實現的BeanFactory非常方便將以上組裝實現。
6.2.2 數據持久層設計(目錄)
數據持久層與數據庫聯系非常簡單，在SPRING的配置文件中配置如下兩步就可。
第一步：設置iBATIS
<bean id="sqlMapClient" class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="configLocation">
<value>WEB-INF/sqlMap-config.xml<!-- iBATIS配置文件--></value>
</property>
</bean>
第二步：數據訪問層(DAO)對象與數據庫配置和iBATIS配置聯系
<bean id="userDao" class="cn.com.mofit.demo.system.dao.SqlMapUserDAO">
<property name="dataSource">
<ref local="dataSource"/>
</property>
<property name="sqlMapClient">
<ref local="sqlMapClient"/>
</property>
</bean>
接下來業務邏輯就可使用這些數據持久層的方法了。
你看不是很方便，開發者在代碼編寫中從來沒感覺到用到Spring什么東東，而且簡化IBATIS操作數據庫的步驟。
數據持久層的開發任務是將業務層傳過來VO值對象轉化為數據庫中對滿足條件的特定操作。
IBATIS引入了動態映射機制，根據配置文件中設定的SQL動態生成規則，創建相應的SQL語句。通過
等一些IBATIS的SQL動態生成規則組合很方便的實現VO值對象到數據庫操作映射。
6.2.3 業務邏輯層設計(目錄)
該類是系統管理模塊的facede類。所有對系統管理模塊的業務操作都應當通過該類完成。
該類會通過配置文件為所有方法增加事務處理。
建議類里面的方法都加上如下前綴，以方便用指定的命名規則設置事務處理級別：
queryXXX() － 不需要，或者只讀事務
addXXX() － 需要事務處理
removeXXX() － 需要事務處理
updateXXX() － 需要事務處理
XXXX() － 其他方法，需要事務處理
這樣，我在TransactionProxyFactoryBean的配置里就可以這樣設置：
<property name="transactionAttributes">
<props>
<prop key="query">PROPAGATION_SUPPORTS</prop>
<prop key="">PROPAGATION_REQUIRED</prop>
</props>
</property>
由于該類的特殊性和事務處理，建議類里面不要有無謂的輔助方法。
我們在CONTROL層引用的業務層實質是業務邏輯層加上事務后的業務邏輯接口。
6.2.4 WEB層設計(目錄)
Controller類負責前臺的，不重要的數據校驗。并調用fa?ade類完成業務。非常干凈利落。
圖七
對應的SPRING配置文件
<!-- 用戶登錄處理類 -->
<bean id="do_login" class="cn.com.mofit.demo.system.web.UserLogAction">
<property name="formView"><value>login</value></property>
<property name="successView"><value>main</value></property>
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>
<!-- 用戶列表瀏覽類 -->
<bean id="do_browse" class="cn.com.mofit.demo.system.web.browseUserAction">
<property name="systemManager"><ref bean="systemManager"/></property>
</bean>
非常輕松的將加上事務后的業務邏輯接口引到控制層，頁面流配置也類似STRUTS。
UserLogAction繼承SimpleFormController，該子類非常適合處理表單提交事件。 它的處理流程是這樣的：
get請求來到時，這樣處理：
1) 請求傳遞給一個controller對象
2) 調用formBackingObject()方法，創建一個command對象的實例。
3) 調用initBinder()，注冊需要的類型轉換器
4) 調用showForm()方法，返回準備呈現給用戶的視圖
5) 調用referenceData()方法，準備給用戶顯示相關的數據。如用戶登錄需要選擇的年度信息
6) 返回formView指定的視圖
post請求來到時，這樣處理：
1) 調用formBackingObject()方法，創建一個command對象的實例。
2) 將請求傳來的參數寫入command對象
3) 如果設置為要求驗證，則調用validator類進行數據驗證
4) 調用onBindAndValidate()方法，該方法允許自定義數據綁定和校驗處理
5) 調用onSubmit()方法，進行業務邏輯處理
結合我們的設計我們可以用command對象，直接將頁面數據通過控制對象傳給業務邏輯處理，當中都不需要類型轉換，非常方便。是不是很合開發者的胃口。
6.2.5 總 結 (目錄)
這個事例非常簡單，但還是能說明Spring的Ioc模式實現的BeanFactory和AOP確實能給我們開發帶來極大方便。我想如果我們有工具將BeanFactory的配置文件生成圖形化的話，將會極大提高我們的開發效率。
以前構建一個持久層是驚人的困難，現在我們想一下結合iBATIS數據持久層的開發，我們將數據持久層構件化是否是個非常簡單的事，現在需要做的僅僅是IBATIS的sqlMap文件生成的圖形化工具，然后是幾個摸版化增刪改查的方法。業務邏輯層對它們的裝配利用Spring的BeanFactory也能輕松實現。
這是個輕量級的J2EE開發的圖形化構件化的解決方案，那么我們EJB老大哥呢？
我想如果單一拋開EJB那么多功能不說，我想就EJB專注做好數據持久層設計構件化這個工作，它有許多優勢的。現在已經有人在這方面做了比較大的突破。
請不要讓我們一起重復數據持久層開發的辛勞，我們不管你用什么技術，我們只是需要較佳從數據庫中交互數據的構件，讓我們在這方面學學MS，而且我們能比它做得更好！
我們需要數據持久層構件化，結合Spring的Ioc模式實現的BeanFactory原理，簡單的讓業務邏輯組裝，要是這兩者都有方便的可視化工具。我想下次開發我們僅僅需要動一下鼠標，拖拉幾個控件，一切搞定。而這離我們到底有多遠，我覺得就差最后的一步！
6.3源碼下載(目錄)
本程序在JDK4.1,TOMCAT 5.0或WebLogic 8.1上測試通過。代碼有詳細注釋，大家看過就能上手。
點擊這里下載demo!
七、BEA能為我們做更多(目錄)
Bea的 WebLogic出色表現有目共睹，尤其是現在WebLogic 8。現在應用服務越來越復雜，我這個用WebLogic6的人突然看到WebLogic 8會欣喜又不知所措，我們還希望Bea能給我們較簡單的解決方案。
突破口在哪呢？就是數據持久層的開發，數據持久層的不依賴某一特定服務器的構件化圖形化開發做好，一切將變得EASY！前面有Spring的Ioc模式實現的BeanFactory和AOP和輕量級數據庫解決方案IBATIS(Hibernate)做急先鋒，我們覺得數據持久層構件化時代已經到來！這樣WebLogic運行見下圖：
圖八
BEA能為我們做得更多？！
BEA下個春季，值得我們期待！
八、總結(目錄)
這篇文章對我來說是個挑戰，但一直以來J2EE開發的快樂與痛苦刺激著我前行。我覺得我們應該為這作些什么。
題目選得有點大，我有幾次想放棄，但我老婆APPLE一直鼓勵著我，讓我在痛苦中成長。
我希望將來的J2EE開發不再會有EJB該如何使用的疑問。因為開發者本身都不會感覺EJB的存在。限于本人水平和理解層次，可能會有許多誤解，期待著與您交流和爭論！
相關資源下載(目錄)
JDK 1.4.2可以從http://java.sun.com下載。
Spring framework 1.1可以從http://www.springframework.org
iBatis 2.0可以從http://www.ibatis.com下載。
Tomcat 5.0、Ant 1.6可以從http://www.apache.org下載。
WebLogic Server / Workshop 8.1可以從http://commerce.bea.com下載。
oracle9I的JDBC驅動，commons-dbcp下載
參考資料(目錄)
Wrox - Professional J2EE with BEA WebLogic Server
J2EE Applications and BEAWebLogic Server
Expert One-on-One J2EE Development without EJB
Expert One-on-One J2EE Design and Development by Rod Johnson
部分圖片來自公司培訓幻燈片
關于作者(目錄)
關于作者：
周必奎（dev2dev ID:zhoubikui），軟件工程師，從事J2EE開發
電子郵件：zhoubikui@eyou.com
地址：財政部信息網絡中心北京興財信息有限公司