J2EE開發框架發展簡史 擁抱更簡單的POJO編程模型
早在1990年，一些商業的ORM工具就出現了，比如TopLink。但由于其價格昂貴、結構復雜并且與Sun的實體bean標準相左，所以很少人會用。不管怎樣，在持久化POJO方面，這些工具與JDBC和實體Bean相比確實有了很大的進步Java Data Object于2001年在Java Community Progress(www.jcp.org)的規范中出現。它為一般的POJO提供了大多數的持久化實現(盡管很多實現都是對關系數據庫的)。但Sun公司以及其他的J2EE技術提供商對該技術表現的很冷淡。所以JDO也沒有能夠流行。
Hibernate的出現。ORM領域在2002年發生了大變化，原因有兩個。首先，實體Beans在實踐中失敗，開發者們將其從J2EE中忽視掉了。它向開發者們說明了一個規范是如何將開發拉入泥潭的。
另外的一個原因是Hibernate的發布(www.hibernate.org)，它是第一個功能健全的解決關系對象映射的解決方案。雖然在功能上，它沒有TopLink多樣。但在那些最常用的功能上，Hibernate實現的更加健壯，并且有一個非常專業的團隊提供全職的開發。Hibernate并不是全新的，它的ORM思想在這個領域很普遍，但它提供的編程模型比其他任何競爭者都容易使用、都來的直接，它為ORM的使用提供了更加易用、廉價的途徑。
與此同時，新一代的商業產品針對關系數據庫提供了極其高效的JDO規范的實現。這樣開發者的選擇就更豐富了；還有，TopLink也朝著開發者友好的方向前進，它的liscense越來越開放了。
ORM大獲全勝。所得這些因素使得ORM比以往更加規范。雖然很多項目仍然使用自己的持久層框架，但Hibernate，TopLink以及一些高端的JDO實現，使得使用自己持久層框架的難度相對變大、可維護性降低，自然，也沒有什么理由去使用自己的框架了。
雖然這些J2EE開發框架的功能覆蓋范圍已經很大了，但仍有很多地方不在其中。比如，一個基于struts，hibernate的項目，業務邏輯很難搞定。盡管對于這種問題，J2EE規范提出了解決方案（EJB），但仍舊沒有一個合適的編程模型。
Spring
J2EE開發框架被大規模地運用到項目中，而項目總要負責這些框架以及自己業務代碼的連接，使之真正融合到一起。Spring就是專注于這個問題的，它和Hibernate融合的很好。
本質上講，Spring是反向控制（IOC）和面向切面編程(AOP)的組合體。它是一個非侵入式的框架，增強了POJO的功能。從服務上講(With a service abstraction)，它將程序代碼從J2EE環境解耦到普通的java對象（自然，這些代碼可以脫離J2EE而在多種環境中運行）。它還在很多功能上提供了除EJB之外的選擇－－比如為所有的POJO提供聲明式事務。Spring被廣泛運用到很多項目中，從小的web程序到大的企業應用程序。
在這個領域還有其他的產品，比如HiveMind (http://jakarta.apache.org/hivemind)和NamoContainer (http://nanocontainer.codehaus.org)。前者和Spring的思想大致相同，只不過在IOC上有較大差異；后者將很多服務融合在PicoContainer的IOC容器中。這些產品的實現方式和J2EE的不同在于，它們都很輕便。
在有J2EE API下做測試是非常困難的，這些容器將POJO從J2EE API中脫離出來，從而大大降低了測試的難度。測試一個普通的java對象，不用象測試J2EE程序那樣，得先將應用程序部署到服務器上，要不就得自己動手模擬J2EE環境。提供日益流行的測試驅動的開發環境（對于開發者來說這是應得的），是這些輕量容器流行的關鍵因素。
下一個將會是誰？
人們日益對開源框架的重視，使得很多項目的成本大大降低，并且投放使用以及維護速度都增加了。現在的開源框架都有很高的質量，都提供了很好的文檔和一些書籍讓開發者做參考。即便如此，兩大因素使得J2EE領域充滿了不確定性：開源領域和J2EE“標準”的沖突和AOP的日益重要。
開源和標準之間的沖突表現在兩個地方。一個是表現層，JSF的身后有Sun公司和其他的一些大公司，而在這個領域有Struts等開源產品與之競爭。在中間層，EJB 3.0采用J2SE5.0的annotations實現了依賴注入(dependency injection)的功能，但這個功能只是Spring的一個子集。
在這兩個領域，開源產品都更加革新。JSP借鑒了ASP.NET，而Tapestry(http://jakarta.apache.org/tapestry)則采用了WebObjects的思想。
同樣的，不知道EJB3.0為何要嘗試著標準化依賴注入，即使這樣會使之不可避免地喪失很多功能。 EJB 3.0好像也要進入程序編寫領域，而J2EE規范在這方面還沒有涉足。
與此同時，AOP的重要性在J2EE社區猛增，在使用上，AOP也越來越受到開發者的青睞。像Spring、dynaop (http://dynaop. dev.java.net)等被稱作“帶著雙拐的AOP”實現提升了AOP的知名度。而純粹的AOP技術比如AspectJ，在將來的幾年也會流行起來。
其次，JBoss (www.jboss.com)通過JCP和EJB3.0保持一致，它極大地推動了AOP技術。但即使如此，JCP 還沒有轉向AOP跡象。
下一代的J2EE規范將擁抱更簡單的POJO編程模型，就像Spring和Hibernate這兩個J2EE開發框架做的一樣。J2EE開發者也注定要從“欺詐客戶”轉到以自己的編程經驗開發上來。這次改變將受到大多數人的歡迎，不像以前那樣每一個新規范發布后，最終都沒有能很好的實現。
【編輯推薦】
