在Twitter領域再次引起了一些反感 ，我看到了Sam Atkinson的博客帖子，題為“ 為什么我討厭Spring” 。 這篇博客文章的撰寫早于2014年，但是DZone后來才真正選擇并發布了它。 實際上，在撰寫本文時，Atkinson是一名開發人員，正在環球旅行。 因此，他個人對社交媒體一定感到非常驚訝。

Atkinson先生的文章觸及了當前Java企業應用程序設計中的幾個有趣的問題：XML配置和編譯時安全性，魔咒，其他Spring應用程序上下文文件的導入和軟件復雜性。 在這篇博客文章中，我將簡要介紹這些內容。

我對XML配置并不感到驚訝，但是后來J2EE 1.3擁有處理EJB XML映射文件的可怕經歷，因此Hibernate持久性在早期也是如此。 最終，Java SE 5注釋和Java EE 5規范幫助改變了一切。 Ruby on Rails的CONVENTION-OVER-CONFIGURATION概念使Java進入了下一階段。 Spring Framework早在2002年和2003年就以可行的依賴關系注入容器實現進入OSS市場。當時，J2EE 1.3 / 1.4令人震驚，混亂的是容器管理的會話EJB和混亂的實體EJB概念。 沒有標準的DI框架，Spring的競爭對手是Pico Container ，更老的Apache Avalon（現在關閉）框架，甚至是Struts 1.x框架。

從2006年開始的幾年后，Java EE出現并在編譯時為Context and Dependency Injection（CDI）1.0提供了強大的類型安全性。 對于成千上萬采用Spring Framework的企業而言，CDI為時已晚，當時大多數企業都在努力從Java 1.4（J2EE 1.4）遷移到Java 5和/或6。十年前的最大問題是使關鍵任務應用程序保持運行狀態在WebLogic Server 7/8或IBM WebSphere 5/6應用程序服務器中。 因此，最先進的技術已經被打破了好幾年。 Spring Framework擁有自己的DI容器，而Java EE 6也具有DI容器，因此永遠不會碰面。

當它最初被構想時， 依賴注入早在2003年就已陷入僵局，當時花了很多時間才能理解面向對象系統的常見問題。 其中最主要的是應用程序的可測試性和Java對象的替代實現的選擇。 在當時，通過將對普通舊Java對象（PO??JO）的實例化的控制權交給外部框架是非常不尋常的。

在水被打破之后，每個工程師都將類和實現推到了框架中，這很可能是我們現在為此付出的錯誤。 當軟件運行時，注入哪些bean以及在哪個應用程序層運行的魔咒非常神奇，但是，就像Sam Atkinson所說的那樣，當您追逐一個錯誤并通過Spring重構其他團隊的依賴關系時，這真是一場噩夢框架。 除了通常的BIT-ROT的人為問題以及軟件開發，SILO DIVISION工程的內部投資銀行文化之外，Spring框架和其他應用程序框架總是在某個時候會丟失。

Sam Atkinson提到了大型應用程序代碼庫的典型LAYERING問題，尤其是當源代碼分成數百個時。 或偶爾有組織內部成千上萬的工程師，測試人員和架構師。 從1.0版開始，Spring框架就已經具有特殊功能， 可以通過在不同的Maven項目中放置不同的bean定義來模塊化應用程序上下文文件 。 該概念非常適合使bean定義與定義和使用它們的模塊保持一致。

也許這種理念非常適合用于足夠小的Maven項目集的應用，一旦組織使用bean定義定義了一百個項目，此技巧就成為了控制的噩夢。 [讓我們不要忘記現在的最新狀態。]在許多相關的應用程序上下文中，結合魔法咒語，分層和大量Spring bean的委派，可能確實導致了Sam Atkinson的巨大認知負擔。 但是，嚴格來講，這不是Spring框架，而是“一切都是釘子”的應用。

最后，軟件復雜性是許多企業的禍根，而構建足夠大的應用程序然后不得不對其進行解密，精簡下來并最終加以替換的后果可能會導致人們的冠冕堂皇 。 Java內最大的復雜性項目也許是Oracle和Sun Microsystems對JDK本身的模塊化，并且完全不使用依賴項注入容器。 Atkinson談到了Spring Boot作為圍繞框架的框架可能帶來的謬論，并且可能存在危險。 他的想法是正確的，因為Java EE還沒有關于完全嵌入式應用程序服務器基礎結構的標準API或JSR。 [Antonio Gonclaves和其他人，包括我自己，都呼吁將這樣的API “一個容器來統治所有人”不止一次地出現。

如果您使用WildFly Swarm之類的產品走這條路，那將存在不確定的路徑，因為您的工具鏈和開發機制可能不會一直支持您。 例如，您的IDE可能無法實現Hot JVM類的重新加載，或者不能對前端頁面內容的更改做出很大貢獻。 這些所謂的無容器解決方案依賴于已經模塊化為單獨組件的應用程序的概念。 如果您的應用程序是一個巨大的BEHEMOTH，那么將其轉到嵌入式應用程序服務器應用程序中將無濟于事。 相反，您需要認真的工作才能到達微服務階梯的第一個梯級，例如嘗試在您自己的組織中取消意大利面條項目和Maven依賴關系。 失敗的原因是無法理解大規模的Spring Framework應用程序僅僅是疾病的癥狀，而不是診斷的癥狀。

我們為什么要輸？ 也許是一個問題，為什么我們現在只是失去它？ 軟件工程中最困難的問題是弄清楚如何使用LEGACY SOFTWARE和DREAMSCAPING。 大多數工程師對遺留軟件和技術債務的概念有所了解。 編寫無錯誤，靈活且敏捷的應用程序非常困難； 堅固且具有極高的可維護性。 大多數技術高級管理人員要么忘記了，要么不相信對遺產的影響。

然后，夢想著招聘公司，有時是公司業務向我們出售工程師，設計師和建筑師。 在九到一千萬的Java開發人員中，大多數都是所謂的GREENFIELD的誘餌。 除非您從一開始就在一家初創公司工作，否則真的沒有這種不起眼的綠色草坪。 即使現有企業催生了SKUNK工作團隊，并承諾在幾周或幾個月內您不必與Legacy合作，您猜怎么著？

您將碰到新的帶鎖系統和舊版舊系統之間的集成。 薩姆·阿特金森（Sam Atkinson）對Spring框架感到沮喪的呼聲的核心是應用程序的架構設計。 在企業現實世界中，絕大多數系統都是BROWNFIELD，請不要讓招聘顧問哄騙您。 他本人說，由于該指令TIME-TO-MARKET較舊，他沒有時間培訓，指導和/或指導組織內的其他開發人員。 這個故事的寓意是，沒有道德，只有我們處于運動技術領先的地位，擊敗Spring Framework，那又如何呢？

我們可以擊敗Java EE或PHP，Ruby和Scala。 如果我們無法控制自己的直覺，時間壓力和設計，良好的老式人性將滲入我們的應用程序，并且我們可以嘗試實現100％的代碼覆蓋率，并使用Cucumber，JBehave編寫最佳的功能測試，我們仍然會失敗未來幾年的應用程序。 軟件就是軟件，我們大部分時間都在虧損，有時我們會贏。 在何時，何地以及如何實現這一宏偉目標非常困難。

翻譯自: https://www.javacodegeeks.com/2015/12/whether-using-spring-framework-not-going-lose.html

總結

以上是生活随笔為你收集整理的无论是否使用Spring Framework，为什么我们会失败？的全部內容，希望文章能夠幫你解決所遇到的問題。

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