在幾年前若你是搞J2EE，並用上EJB（Enterprise Java Bean）技術，會被人投以欽羨崇拜的眼光，J2EE有如專業與高手的代名詞，常被人遠觀而不可褻玩焉。J2EE會被認為是個艱深難懂，挑戰層次頗高的複 雜技術，其中又以EJB的相關技術，名列J2EE排行榜榜首。難道J2EE的應用程式非得搞得這麼不易近人嗎？光設計一個EJB就得實作三個標準介面，多 出了不少程式碼需要撰寫，如此在規劃大型應用系統時，程式數量是相當可觀的，從設計到測試的成本實在令開發者汗顏。
EJB技術門檻高，想學好還真的不容易
想當初筆者剛開始研究EJB時（應該是1.1版吧），光搞懂EJB整個技術架構就花了不少時間，還好當時拜讀《Mastering Enterprise JavaBeans》釐清了不少觀念，該書算是當時EJB技術領域實屬難得的好書之一。作者Ed Roman以流暢的文筆及有系統的章節編排，詳細介紹整個EJB技術及建議的實作方針，廣度與深度並俱，可以讓新手循序漸進地學習，目前已經出到第三版， 是開發人員在撰寫EJB時值得參考的一本實戰指南。
由於開發EJB相關應用程式實屬不易，J2EE開發人員常透過強大的Java IDE開發工具（像是Eclipse、Borland JBuilder、IBM WSAD等），甚至搭配類似XDoclet的程式產生器，協助快速開發EJB元件，不過這些工具雖然可以少去撰寫一部份的EJB程式碼，但問題是EJB元 件測試都必須佈署到Container後才能進行，造成整個開發過程時間拉長，加上採用不同廠商的Application Server產品時，也許又會發生不同的問題，常常讓開發人員一個頭兩個大，挫折感油然而生。
以銅為鏡正衣冠，以人為鏡明得失
許多同好在開發EJB時常常碰釘子，所以你會發覺在坊間的書籍中、網路社群討論的話題裡、或是Java技術研討會中，找到或聽到許多已經被 J2EE凌虐多時的專家先進們，提出不少前車之鑑避免重蹈覆轍的良心建議，繞過費時費力的開發方式。不管是在設計模式（Design Patterns）或最佳實踐方案（Best Practices）的議題上，在當時整個J2EE的核心技術尚未能有革命性的突破時，這些都被視為設計J2EE應用系統的架構聖經，必須詳細拜讀且乖乖 遵循才行，因為實在是被惡搞到怕了。
討論J2EE設計模式的書籍中，以最具代表性的《Core J2EE Patterns：Best Practices and Design Strategies》為經典，本書作者Deepak Alur等專家分別針對J2EE的不同層面（Presentation、Business、Integration）來進行因素分解，利用J2EE本身技 術的特性，列舉出適合的設計模式讓讀者參考，闡述每個模式的使用時機及其優劣之處，為四人幫《Design Patterns》之後，在J2EE領域談論設計模式之先例。
要用EJB，看看專家怎麼說？
而在《EJB Design Patterns》書中，作者Floyd Marinescu提出了許多在實務上，設計EJB時常用到的設計模式。由於EJB本身的技術特性，在實務設計上針對各種不同的情境及狀況（像是 Session Facade、Data Transfer Object等設計方式），作者都提出了建議的做法。
值得令人玩味的是，該書第八章亦提出了非Entity Bean的Persistence解法（JDBC/DAO或JDO），尤其在大量資料存取的情境下，可能會因為產生過多的Entity Bean而影響效能，作者已經試圖以非EJB技術來處理相關問題。Bruce A. Tate在《Bitter EJB》書中更是以反向思考的方式，討論實作EJB技術時，應該避開的設計陷阱，提出對於EJB技術適當的使用時機，強調EJB並非解決所有難題的唯一途 徑，需要謹慎考慮評估。
在一些中小型規模的軟體專案中，EJB技術中較常被採用的以Stateless Session Bean較多，而Stateful Session Bean、Container Managed Persistence Entity Bean反倒是乏人問津，在抽象化的物件設計來看，Entity Bean很難直接表示領域物件（Domain Object）的需求，因為它在物件與關連式資料庫之間對應（O/R Mapping）的機制上仍然有不少限制，像是不易表達資料表之間較複雜的關連性，無法直接滿足領域物件的需求，讓Entity Bean在設計階段時，物件數量居高不下，不太合乎設計抽象化的基本精神。慢慢地，Entity Bean的採用率愈來愈低，取而代之的是簡單的DAO設計模式。
J2EE + Design Patterns =消化不良？
換個角度來思考Design Pattern及Best Practices背後代表的意義，這些即是累積了前人的不斷試誤歸納而成的經驗法則，這樣的經驗在技術門檻高的狀況下需求更是殷切，入門級的新手想要快速上手，便得乖乖的跟隨著前輩的腳步，以免誤入歧途。
所以你會發現前些時間只要書名掛上這些字眼的都賣得不差，突然之間大家都開始重視這模式導向設計（Pattern-Driven Design）的議題，這也是千百個不願意呀！不過設計模式本身亦是個抽象度極高的概念，對一個缺乏實務經驗的入門級開發者，同時要吸收J2EE技術及設 計模式，消化不良是必然的。
Nissan March再怎麼保養，吃再好的機油，駕駛員技術再好，跑起來還是不可能比Mercedes-Benz來得快。不過就算這些大師們提出了不少值得參考的見 解，但在EJB技術架構不變的大前提下，能夠改善的空間仍然十分有限。前提是Nissan March與Mercedes-Benz訴求重點並不儘相同，將他們直接拿來做比較，是稍嫌殘忍了點。
殺雞焉用牛刀？
真的複雜的需求只有透過EJB才能解決嗎？單純以POJO（Plain Old Java Objects）的方式也難以實現嗎？有沒有其他的軟體框架可以取代EJB Container？相信這些問題都是當時許多J2EE開發者一直想了解的。
所以有些專家們受不了被EJB不斷荼毒，便開始有一些替代技術紛紛出現。最先針對EJB Entity Bean機制有了iBATIS、JDO（Java Data Objects）、Hibernate等開放源碼框架，簡單地透過POJO的核心，發揮物件關聯對應關係（ORM、Object Relational Mapping）的功能，其中包括了在應用程式對資料庫進行存取時最重要的資料永續（Database Persistence）及交易管理（Transaction）機制。
這些技術都秉持著輕薄短小的特色，完完全全推翻了原本EJB Entity Bean肥厚的複雜作法，省略了Bean複雜的生命週期，去掉了繁瑣的佈署描述檔，而且提供了對於關連式資料庫的資料抽象化功能，讓應用系統對資料庫的存 取直接對領域物件操作，物件的設計更能符合抽象化的概念，大幅減少開發人員所需花費的時間。
另外在傳統物件之間依序性的關係，也被注入新的行為模式。IoC（Inversion of Control）、DI（Dependency Injection）、AOP（Aspect-Oriented Programming）陸續被廣泛討論，物件導向設計的概念又有了革命性的思維。利用宣告XML組態檔的方式來定義物件之間的關係，讓物件之間耦合性 （Coupling）更低，更能發揮物件重用的精神。相關的軟體框架也陸續被推廣使用，像是AspectJ、PicoContainer、Avalon 等，最有名的不外乎被公認是「春天來了」且令人「如沐春風」的Spring Framework了。
J2EE邁向輕量級發展的重要里程碑
在《Expert One-on-One J2EE Development without EJB》一書中，作者Rod Johnson（Spring Framework之父）從EJB的演進史開始，探討為何這樣的技術一直未被市場廣泛接受的原因，質疑EJB這個複雜技術的必要性，開宗明義就提出不需要 用EJB，也可以設計出企業級的應用系統，當然這裡提到的另類解法便是Spring Framework。由於作者親身參與Spring的發展歷程，書中提出許多十分精闢的見解，值得讀者深思。在他的另一著作《Professional Java Development with the Spring Framework》中，對此技術有更深入的介紹。
而在《Better, Faster, Lighter Java》中，作者Bruce Tate也不約而同站在同一陣線，倡導如何以更輕薄，更簡潔的方式，來達成J2EE應用系統的瘦身計畫。他指出開發人員常會使用過度複雜的技術，只是用於 解決十分簡單的需求，而落入技術本位的迷思中。在他的書中更是將Spring及Hibernate這些輕量級的軟體框架視為EJB的替代方案，並配合敏捷 開發（Agile Development）及XP極限軟體製程（eXtreme Programming）將開發流程調整得更有效率。
Java界颳起POJO的極簡風
根據Martin Fowler、Rebbecca Parsons，及Josh MacKenzie在2000年提出的想法，POJO是一個未實作任何特定介面（Interface）的Java元件，其結構簡單且易於實作。當時這些專 家提出取代Entity Bean的作法，希望以一個特殊的名稱來代表這樣的精神，同時希望能被廣為流傳，故以POJO為命名。
而作者Chris Richardson在《POJOs in Action》書中亦提到POJO的本質，是讓開發人員容易進行程式撰寫、功能測試、維護及需求變更等工作，使整個開發流程趨於簡單快速，避免因為技術複雜度過高，引發太多的不確定風險，進而有效提高生產力。
在《POJOs in Action》書中便提到如何結合當今流行的輕量級軟體框架，將POJO的設計理念套用在J2EE架構上。與傳統EJB技術相較之下，POJO降低了開發 所會面臨的複雜度，而且執行時期的環境也擺脫了厚重的EJB Container，在系統資源上更能有效運用。
更能專注在商業邏輯的設計
採用POJO真的可以減少開發人員的負擔嗎？《POJOs in Action》書中一開始便以傳統銀行轉帳的範例，說明利用POJO與EJB之間進行系統設計及開發方式的差異，從設計模式、資料永續機制、交易管理、到 最後的部署，POJO突破了EJB受限於僅能在EJB Container中運行的限制，既有的程序化開發方式，讓你更能專注於商業邏輯元件的設計開發，而不會因為受限於Container的機制而彆手彆腳。 而在決定採用POJO或者EJB 2.1時，本書亦透過範例來逐步分析，討論在設計階段所必須要考慮到的重點，這些重點則直接影響選用的技術為何。
由於先天特性的不同，當以POJO為主要設計方向時，整個設計決策亦與傳統的EJB架構有所不同。作者一直反覆提醒讀者的領域模型（Domain Model Pattern），則為採用POJO方式進行開發時所必須重視的，因為領域模型為設計架構的重要來源，系統架構統一以領域物件做為操作的對象，可以讓系統 更為單純容易。透過輕量級的資料永續框架，直接將領域物件轉化成POJO程式碼，且完成與資料庫之間的對應關係，更能符合Domain Model的精神。
多種資料永續機制供你選擇
企業應用系統免不了在與資料庫之間，作者針對建立動態資料查詢機制，交易鎖定及同步存取管理都有專章說明。本書分別搭配不同的軟體框架 （iBATIS、JDO、Hibernate、EJB3）來實作，而非僅限於一種解法，可以感受到作者的用心良苦，讓讀者可以從中比較之外，也可以客觀分 析彼此之間的差異。而作者精確的分析內容，也讓提出的論點及整個實作結果更具可信度及參考價值。
POJO的重新被重視，代表著J2EE輕量化的時代來臨，Spring Framework的意氣風發，使得EJB的發展也受到影響，EJB 3.0也不得不將POJO的設計理念納入核心架構中。在本書的第十章亦介紹了EJB 3.0的新功能，以及和以往設計的相異之處，並且說明了透過EJB 3.0與POJO實作的細節，讓讀者可以了解EJB3的新面貌。
KISS: Keep It Simple & Smart
延續著《Expert One-on-One J2EE Development without EJB》、《Better, Faster, Lighter Java》等書的中心思想，本書除了的基本論調與這兩本書雷同外，另加入更多在設計建議及實作細節的內容，詳細的程式碼，讓讀者可以一步步體會作者欲表達 的真正理念。
當然，每一項技術都有其優劣之處，POJO也不例外。也因為透過宣告組態檔來定義物件之間的關聯性，若你已採用Spring Framework進行軟體開發，面對功能點較多或規模較大的應用系統時，維護冗長複雜的組態檔也是令人十分頭大。大家也不需要因為業界流行，過度吹捧 Spring、Hibernate的優點，重點是依你的需求選擇合適的技術架構。技術本身是無罪的，端看你如何在正確的時機運用它。
另外，在Spring Framework與其他輕量級軟體框架尚未列入J2EE官方標準前，社群的力量固然重要，但商業軟體大廠的加持與背書更是需要，畢竟市場使用的普遍性仍需要標準來主導，讓好用的技術能夠成為真正的主流，這才是Java普羅大眾的福祉。
