spring javaee

在Java社區中，Spring vs JavaEE是一個永無止境的爭論。 在這樣的辯論中，人們組成一個團體，由兩個傳播者，建筑師和一個平臺的核心粉絲組成，并且不斷進行辯論。 參與辯論的人可能是負責平臺選擇的架構師。 但是開發人員會如何看待這次Spring vs JavaEE辯論？

我是同時使用Spring和JavaEE的Java開發人員，并且不屬于Spring或JavaEE粉絲俱樂部。 在這里，我想就這個史詩般的Spring vs JavaEE辯論分享自己的想法。

1.商業（有時是政治）方面

在許多組織中，技術選擇可能并不完全取決于開發人員的選擇。 更具體地說，如果您在所謂的巨型企業組織中工作，那么很有可能會有架構團隊來決定在項目中使用哪種平臺/語言/框架/庫。

除此之外，大型企業在選擇技術平臺時還考慮以下方面：

• 平臺/語言/框架/庫的成熟度
• 商業支持
• 許可費用等

作為開發人員，我幾乎不會影響上述任何方面的決策過程，尤其是當我是離岸開發中心的開發人員時。 所以我不用太擔心這些事情。

2.如果您真的很擅長Spring / JavaEE，那么學習另一個也不應該很困難

當有人說我是JavaEE專家但我聽不懂Spring時，我總是感到驚訝。 JavaEE和Spring都在相同的核心API（Servlet，JPA，JMS，BeanValidation等）上工作，不同之處在于誰將Spring或AppServer粘合在一起。

即使對于諸如依賴注入（Spring DI，CDI），REST（JAX-RS，SpringMVC）等事物有一些不同的API，它們的外觀和行為也非常相似。

也許有人可以說CDI比Spring DI更安全。 在以下情況下，Spring和CDI的行為不一樣嗎？

• 如果只有一個Spring / CDI Bean，則使用@Autowired或@Inject進行注入可以正常工作
• 當存在多個Spring或CDI bean實現時，注入失敗，并拋出錯誤：“找到了多個可以注入的合格bean”，注入失敗。
• 使用@Produces或@Bean注釋方法將自定義對象提供為Bean提供程序

只要它們的行為類似，我不在乎它們是以類型安全的方式實現還是在其內部實現中使用基于String的映射。

怎樣才能成為Spring的專家，卻不懂JavaEE，反之亦然？ Spring專家學習JavaEE需要多少時間？

3.對“ Average Joe開發人員”更友好

我認為，到目前為止，很多人應該已經意識到，一項技術的成功可能并不完全取決于其優點，還取決于開發人員的采用。 要實現的最重要的事情是“并非每個軟件開發人員都是搖滾明星開發人員。 與熱情的技術忍者相比，普通的joe開發者更多”。 因此，為了使人們適應任何框架，它應該對“ Average Joe Developer”友好。

我認為Spring通過提供更多工具（例如SpringBoot，用戶指南等）來做得很好。SpringSecurity，Spring Integration，Spring XD，Spring Social很好地滿足了現代業務需求。 還請考慮一下Spring提供的各種模板，這些模板使操作變得簡單而無需擔心樣板代碼。

通過引入JBossForge，Wildfly Swarm等快速入門，JavaEE也表現出色。 我遇到了一些基于JavaEE的框架，例如Picketlink，該框架可以解決安全性要求，但是我覺得它比應該的要復雜得多。

我要傳達的觀點是“您可以使用Spring進行JavaEE中的幾乎所有工作”。 區別在于，這讓普通的joe開發人員可以立即使用。

4.沒有上下文的arguments腳論點

每當Spring vs JavaEE辯論出現時，人們就會組成兩個小組，并不斷進行辯論。 不幸的是，辯論集中在一些無用或過時的觀點上。

XML重：

JavaEE愛好者首先開始說Spring是XML的重頭戲，我討厭XML等等。 如果您仍在使用早于2.5版的Spring并假設它仍然基于XML，那么我的朋友應該醒來，并轉到http://spring.io

EJB不好（或）JSF不好

Spring迷們像EJB 2.x或JSF 1.x一樣猛撲EJB和JSF。 如果他們真的關注EJB 3.x和JSF 2.x，那么他們根本不會爭論。 不要憑著6年的EJB2.x經驗來判斷EJB3.x。

重或輕

我對“重量”的解釋是基于運行時的足跡。 據我所知，當您將托管bean部署到JavaEE容器中時，容器將代理它并注入所有企業服務（事務，安全性等），如果是Spring，它將由Spring AOP完成。

我沒有任何度量標準可以說哪個是比較重的Container Proxy或SpringAOP Proxy，但是我想可能沒有太大的區別。

有些人將戰爭檔案的大小視為其“重量”。 在那種情況下，將（JavaEE AppServer + war）大小與（帶有126個jars的SpringApp）進行比較，看看哪一個重量輕:-)

JavaEE是基于標準的

拜托了伙計們！！！！

供應商鎖定

我認為選擇一個不會讓您堅持某個特定供應商的平臺是好的。 但是，僅基于遷移到其他實現的能力來選擇選項是不正確的。 一年中從一臺服務器切換到另一臺服務器多少次？ 選擇不與供應商鎖定您的平臺是“很不錯的選擇”，但這不是選擇平臺的主要因素。

我們不需要外部庫

這稱為“為爭辯而爭辯”。 向我展示任何沒有依賴關系的真實應用程序。 如果您說我要開發自己的日志記錄庫，我要編寫自己的HTTP客戶端，我要開發自己的通用工具，那么您需要尋找一些沒有“重新發明”的懶惰的架構師/開發人員。所有輪子的疾病。

5.不要看著人群說“你們都是白癡，因為您使用X，所以應該遷移到Y”。

這是我在許多社區站點上觀察到的常見模式，尤其是在Reddit上。 只需發布與JavaEE vs Spring相關的任何東西，就會有兩個小組像其他一樣抨擊另一個小組，因為另一個小組沒有使用他們喜歡的平臺。

想一分鐘。 如果說Spring不好，為什么會有很多人使用它并喜歡它。 如果JavaEE不好，為什么會有很多人從Spring切換到JavaEE。 每個平臺上都有很多好東西。 尊重他人選擇他們選擇的任何選項。 如果可能的話，請問他們為什么選擇彼此的理由，并了解您是否錯過任何事情。

只是說“你們都是不使用我喜歡的選項的白癡”并不能使他們使用您喜歡的技術。 實際上，這觸發了人們的想法，提出了您最喜歡的平臺爛點的清單。

如果您確實希望他們切換到自己喜歡的平臺，請通過代碼示例顯示原因。 向他們展示使用您喜歡的平臺和示例應用程序開發應用程序有多么容易。 寫更多有關常見問題及其解決方法的文章。 將“ Average Joe Developer”安裝到您喜歡的平臺上。

作為一個熱情的Java開發人員，我閱讀了Spring vs JavaEE的討論，希望可能有一些我不知道的事情，例如“在哪個領域比另一個領域更好”。 但是我發現70％的討論都是關于la腳的爭論，這對我來說不是很有趣。

我希望Spring和JavaEE陣營之間的戰斗越來越多，并使他們的平臺比其他平臺更好。 歸根結底，無論誰贏得了辯論，最終開發人員都將擁有更強大的平臺。

翻譯自: https://www.javacodegeeks.com/2015/06/a-developers-perspective-on-spring-vs-javaee.html

spring javaee

總結

以上是生活随笔為你收集整理的spring javaee_开发人员对Spring vs JavaEE的看法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。