開發者眼中的Spring與Java EE

infoq發表於2015-07-11

  在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更夠形成良性競爭,讓自身變得越來越好。這樣,無論誰最終贏得了競爭,受益的還是廣大開發者們,因為他們擁有了更為強大的平臺。

相關文章