開發人員眼中的Spring與Java EE

標籤：

本文來源於我在InfoQ中文站翻譯的文章，原文地址是：http://www.infoq.com/cn/news/2015/07/spring-javaee

在Java社區中，Spring與Java EE之爭是個永恒的話題。在這場爭論中，來自兩個陣營的佈道師、架構師與鐵杆粉絲都在不遺餘力地捍衛著本方的尊嚴，並試圖說服對方加入到自己的陣營當中，但結果卻是雙方都很難說服對方，每一方都有充分的理由表明自己的選擇是正確的。參與到這場爭論的有一些架構師，他們負責著平台的選擇。那麼對於普通開發人員來說該如何思考這場曠日持久的Spring與Java EE之爭呢？

Siva是一位充滿激情的Java開發人員、開源佈道師、知名博主，擅長Java、Struts、Hibernate、Spring等各項技術與架構。Siva既使用過Spring，也使用過Java EE，但他既不是Spring的鐵杆粉絲，也不是Java EE的忠實追求者。相反，他對於Spring與Java EE有著自己的理解和認識，並且在項目當中會根據具體需求選擇適合的技術。近日，Siva分享了他對於Spring與Java EE的一些認識和理解，希望能對各位讀者起到協助作用。

業務方面

在很多組織中，技術選擇並不完全是由開發人員決定的。具體來說，如果你工作在一家大型的企業組織中，那麼極有可能會有一個專門的架構師團隊負責決定在項目中該使用什麼平台、架構與庫。除此之外，大型企業在選擇技術平台時還會考慮如下幾個方面：

• 平台、語言、架構與庫的成熟度等級
• 商業支援
• 許可費用等

作為一名開發人員，你可能無法影響上述幾方面的決策制定過程，特別是對於那些處於離岸開發中心的開發人員來說更是如此。因此，對於開發人員來說，你可能無需過多關注於上述幾個方面。

如果你非常熟悉Spring，那麼掌握Java EE也不是什麼難事，反之亦然。

我非常奇怪有人會說他是個Java EE專家，但卻無法理解Spring，反之亦然。無論Java EE還是Spring都使用了同樣的核心APIs（Servlet、JPA、JMS、BeanValidation等），差別在於到底是什麼將這些東西粘合到了一起，是Spring還是應用伺服器。

雖然對於依賴注入（Spring DI、CDI）、REST（JAX-RS、SpringMVC）等存在著不同的APIs，但他們彼此之間的行為卻是非常類似的。可能有人會說CDI在型別安全上要比Spring DI更好，比如說：

• 如果只有一個Spring/CDI Bean，那麼使用@Autowired或是@Inject都是沒問題的。
• 如果有兩個Spring或CDI Bean實現，那麼注入就會失敗並拋出錯誤，說“找到了多個可注入的對象”。
• 使用@Produces或@Bean註解的方法可以實現自訂的Bean提供器。

只要二者行為類似，那麼我就不關心誰的實現是更加型別安全的，誰在內部實現中採用了基於String的映射。我想說的是，怎麼可能有人是Spring專家但卻無法理解Java EE呢，反之亦然。一個Spring專家要花多長時間才能掌握Java EE呢？

Spring與Java EE哪一個對開發人員更加友好呢？

我認為到現在為止，很多開發人員應該能夠認識到一項技術的成功與否其實並不完全取決於自身的優缺點，還要取決於開發人員的使用率。我們要認識的重要一點是：“並不是每一個軟體開發人員都是明星開發人員，還有很多處於中等水平的開發人員”。為了讓人們能夠使用某一個架構或技術，架構或技術本身要貼合這一部分人的需求。我覺得Spring在這方面做得非常好，它提供了諸如Spring Boot、使用者指南等工具協助開發人員上手。Spring Security、Spring Integration、Spring XD、Spring Social等項目都很好地解決了業務的需求。此外，Spring還提供了各種各樣的模板，讓人們能夠輕鬆上手開發而無需編寫大量的樣板代碼。

Java EE也通過JBoss Forge、Wildfly Swarm等工具協助開發人員上手。除了Picketlink之外，我幾乎看不到有哪些Java EE架構提供了安全解決方案；但即便是Picketlink，我覺得也過於複雜了。我想表達的觀點是“Spring能做到的事情，Java EE基本上也都能做”。區別在於哪一個會為普通開發人員提供開箱即用的支援。

缺乏內容相關的爭論

當Spring陣營與Java EE陣營的人開始爭論時，註定是沒有終點的。但遺憾的是，爭論很多時候都圍繞著毫無意義或是過時的點上面，比如說下面這些：

大量使用XML

Java EE粉絲一開始就會說Spring大量使用了XML，我憎惡XML之類的。如果你還在使用Spring 2.5以下的版本，然後就認為Spring中充斥著大量的XML，那麼我想說你醒醒吧，到http://spring.io看看。

EJB與JSF都是垃圾

Spring粉絲會猛烈抨擊EJB與JSF，就好像他們還是EJB 2.x或JSF 1.x那樣。如果仔細看看EJB 3.x與JSF 2.x，那麼他們就不會有這個想法了。不要拿6年前EJB2.x的老眼光看待現在的EJB 3.x。

重量級與輕量級

這裡的“重量級”指的是運行時情況。在將託管Beans部署到Java EE容器中時，容器會為其組建代理程式並注入所有的企業服務（事務、安全等），對於Spring來說，則是通過Spring AOP來實現的。這裡其實沒有辦法判定哪一種方式更加重量級，容器代理呢，還是Spring AOP代理，不過我覺得二者之間的差別並不太大。有些人會將部署的war包大小作為判斷是否“重量級”的一個依據。在這種情況下，Java EE應用伺服器 + war與Spring App + 126 jar之間的差別倒是很明顯。

廠商鎖定

我認為選擇平台時可以不依賴於某個特定的廠商是很重要的，不過純粹基於可以遷移到另外一個實現這一理由來選擇平台也是不恰當的。可以想想，你有多少機會會從一個伺服器遷移到另外一個伺服器？選擇一個平台時不必鎖定到某個廠商是個“錦上添花”的行為，但絕不應該將其作為關鍵因素。

我們不需要外部程式庫

這就是所謂的“為了爭論而爭論”。給我看看有哪個應用不需要其他依賴？如果你說你要開發自己的日誌庫，編寫自己的HTTP用戶端、開發自己的通用庫，那麼我只能說這樣的開發人員也算是奇葩了，放著現成的不用，還要“重新發明輪子”。

你現在使用的是X，你應該遷移到Y

我發現很多社區網站都存在這樣的觀點，特別是在Reddit。當有人發出關於Java EE與Spring的文章時，就會有兩撥人蔘與進來，猛烈抨擊對方，原因就是對方沒有使用自己鐘愛的平台。先想一想，如果Spring是垃圾，那怎麼還會有那麼多人使用並喜歡它呢。如果Java EE不好，那為何還會有人從Spring遷移到Java EE上呢。每個平台都有長處。你要做的就是尊重他人。如果可能，問一下他們為何要選擇這個平台，是不是有你不知道的理由在裡面呢？

作為一名熱情的Java開發人員，我真心希望在關於Java EE與Spring之間的爭論中能找到我之前不瞭解的東西，比如說“在哪些情況下，Spring要比Java EE更合適；在哪些情況下，Java EE要比Spring更好”。我希望Spring與Java EE更夠形成良性競爭，讓自身變得越來越好。這樣，無論誰最終贏得了競爭，受益的還是廣大開發人員們，因為他們擁有了更為強大的平台。

InfoQ也發表過多篇關於Spring與Java EE之間比較的文章，那麼親愛的讀者，你對二者有哪些看法呢，不妨與大家共同分享。

開發人員眼中的Spring與Java EE