Spring 和EJB終於統一融合

banq發表於2008-09-20
Spring
Spring 和EJB爭吵終於即將結束：Spring將支援EJB3.1標準，Spring will also be a full featured EJB 3.1 implementation for use in the WebLogic application server.這場融合將在javaEE 6實現，這個融合和當初Hibernate與JPA融合一樣水到渠成。

Spring創始人Rod Johnson 說Spring 2.5的dependency injection annotations是學習得益於EJB 3.0的 @Resource 和 Google's Guice，我不知道他為什麼沒有提picocontainer，至少他的Spring 2.5開始直接大膽使用DI的auto wiring（而這個功能在Spring 1.X中還是可選功能），而2005年我的Jdon框架就完全是auto wiring。

Rod Johnson 鼓勵開發者使用EJB標準，比如 @PostConstruct 和 @PreDestroy annotations，因為他們是標準化的，Spring已經支援他們（Spring才支援它們？今天才明白？），這些都意味著Spring和EJB爭吵的結束。

其實EJB的@PostConstruct @PreDestroy @Resource 這樣annotations都可以在EJB2中找到影子和原根，表現語法不一樣，但是內部機制原理是一致的。所以，以前沒有學過EJB的，看來還是要補這一課。

PostConstruct和PreDestroy都是在物件生命週期開始以及結束讓程式設計師能夠進行一些狀態管理，比如開始一些場景準備和載入，或者結束後，釋放一些資源，防止記憶體洩漏，這些都是從EJB1.X 無態Bean開始就有的功能，不過當初是使用XML配置，並且無論程式設計師實現與否，一定要寫這幾個方法，現在透過註解 annotation 加在你需要實現的方法上，更加簡潔方便。

所以，我以前說：如果說EJB1/EJB2X是一個定型的女孩的話；那麼EJB3引入IOC/DI依賴注射和annotation以後，就更漂亮，更加吸引程式設計師接近她，也非常容易和其打交道了。

EJB從開始誕生起，因為高低各種原因，被高階和低端各種人懷疑打擊，真正是遭受了不公平待遇，

高階專家比如Martin Fowler因為其不宜測試，提出POJO思想，認為物件應該不依賴平臺，應該是一個個光溜溜來去無牽掛的，不繼承任何框架介面等。不可否認POJO促進了EJB3變得更漂亮，但是EJB內在分散式計算元件的重點沒有變。

在低端程式設計師中，EJB以其深奧的原理和超前的設計思維，更不能被他們理解，他們甚至以一種僵化思維來看：現實80%不是大系統，不需要叢集分散式計算。

他們這種思維去炒股票肯定輸得血本無歸，因為，他根據他看到的80%股票下跌，20%上漲，因此決定自己是進入80%的股票還是進入20%股票，這種以過去經驗的僵化思維來決定未來的策略和“守株待兔”沒有區別，今天看到一隻兔子撞死在樹下，明天就在這裡等，以為同樣事情發生。

你今天做的系統在以後幾年可能不需要叢集，不需要對付大訪問量，但是你能保證你做的每個系統都是這樣，你為什麼要等這個系統真的可能被某個風險資本看中，發展為全國系統，抗不住大訪問量時，再去救它嗎？為什麼不在當初系統架構設計時，以較小的代價設計一個可伸縮的 有預先的系統呢？

我一直主張“資料庫已死”，因為正如Hibernate創始人Gavin King說說：資料庫是最不具有伸縮性的，不具伸縮,就是沒有彈性，就是阻礙我們將整個系統設計成可伸縮 靈活系統的絆腳石，這樣技術不宣佈其死刑，又能如何呢？

我宣揚的這些思想是一個很高很深刻的架構思維，就像我們追求設計模式，因為軟體不是將功能做好就夠了，要考慮將來維護擴充時的方便，好不容易不少人接受模式，但是他們更多不知道為什麼要使用模式。否則，他們就不會那麼不理解“資料庫好好的，為什麼讓它死，沒用嗎？”

所以，從Spring和EJB爭論，以及最早的EJB CMP和Hibernate爭論中，都可以看出國內大多數程式設計師盲目跟風，沒有自己思維和觀點的特點。

現在我們追求領域建模，認為資料表建立只是程式部署執行時實現的，而不是在程式編寫之前或編寫時建立的，EJB CMP最早提供了模型自動建立資料表的功能，但是大多數人只看到EJB這樣一個超前產品的缺點，包括Gavin King本人，但是自從他進入EJB 3.0專家組以及他對EJB的逐步瞭解，他已經是EJB的擁護者，並推出基於JSF+EJB3的框架Seam。

我一直也奇怪，為什麼EJB這樣超前標準得不到大多數程式設計師的理解，不是EJB太高，而是我們程式設計師太弱，在物件導向上是空白，在分散式計算上更是幼稚。

對於那些盲從Spring的擁護者來說，原來他們說有了Spring就足夠，不需要學習EJB，現在Spring 2.5新增的這些註解，同樣他們付出學習EJB一樣的精力，在我們程式設計師中，對物件生命週期 狀態管理等極其薄弱，

因為程式導向背景的限制，變數函式在執行時情況是統一一致的，而java中一個類在執行是可以有多個例項，也可以有一個例項，每個例項能夠存活多長時間，從什麼時候開始建立誕生，如何能夠被垃圾回收機制順利回收，結束自己的生命週期，這些都掌握不到位。

從Spring和EJB這場爭論中，從名義上看，是EJB標準取得了最終勝利，但是，也正是Spring和Hibernate的競爭，促進了EJB走向完美。Rod Johnson也從當初狂喊"J2EE without ejb"的大忽悠，轉變到現在鼓勵大家使用EJB標準，因為他明白了，可是他那些盲從者不知明白了沒有。

沒有明白的就開始嚼嘴皮子了，玩語言遊戲：EJB3還是按照Spring寫的標準呢？這完全是一廂情願的想法：上面談的Spring 2.5那些@PostConstruct註解早就在EJB3.0裡就有，EJB3.0是先於Spring推出Annotation的，EJB內在的有態物件管理自從EJB1.X就有，Seam更是將EJB推向應用高峰。我們從Jboss Seam的受歡迎程度已經可見一斑，現在找工作，不懂SEAM恐怕就象當初不懂Spring一樣不時髦。

本人Jdon框架從一開始也提供了Session有態管理，當時我也在J道指出了Spring1.x無狀態管理的缺點，雖然Spring2以後開始提供scope="session"，但是到現在2.5版本才提供預設的依賴注射自動配對，可見Spring2以後版本在某些方面似乎在“補課”。

如果說Spring對EJB3有所促進的話，就是其依賴注射IOC/AOP設計思想。由於和AOP冠軍ApectJ融合，致使其在AOP方面的強大是首屈一指的。可惜實踐中我們發現，語言級別的AOP才可能是我真正需要的，我需要修改執行中物件的屬性和方法，這些如果JVM能夠提供將是一個躍進。

所以，無論是Spring向EJB匯合，還是EJB向Spring匯合，這些都已經不重要，因為他們已經不再分裂，而是一個統一名稱EJB。從Spring誕生引起的潮動到今天與EJB合一的解釋以及Seam的熱捧等這一系列事件中，可以看出：如果我們程式設計師自己不具備深刻的OO思維，不具備高度的架構思想，不具備專業的軟體設計思想，面對國外瞬息萬變的各種思潮，就只能發生盲目崇洋，盲目跟風，甚至東施效顰。

End of Spring vs EJB wars in sight?

http://www.ryandelaplante.com/rdelaplante/entry/end_of_spring_vs_ejb

本站以前Spring與EJB討論：

關於SPING與EJB的胡言亂語--重和輕永恆的話題

http://www.jdon.com/article/24513.html

探討Spring框架使用真相

http://www.jdon.com/AOPdesign/spring2.htm

轉貼：Spring vs EJB

http://www.jdon.com/article/18904.html

EJB3與EJB2架構對比

http://www.jdon.com/artichect/EJB2_EJB3.html

專案規模的界定!

http://www.jdon.com/jivejdon/thread/17993.html

可伸縮性和重/輕量，誰是實用系統的架構主選？

http://www.jdon.com/jivejdon/thread/15634.html

EJB2.x已死

http://www.jdon.com/jivejdon/thread/17995.html

Why “J2EE Without EJB”?

http://www.jdon.com/jivejdon/thread/16699.html


[該貼被admin於2008-09-25 08:25修改過]

相關文章