Spring常犯的十大錯誤具體是什么

1、錯誤一：太過關注底層

我們正在解決這個常見錯誤，是因為 “非我所創(chuàng)” 綜合癥在軟件開發(fā)領域很是常見。

癥狀包括經(jīng)常重寫一些常見的代碼，很多開發(fā)人員都有這種癥狀。雖然理解特定庫的內(nèi)部結構及其實現(xiàn)，在很大程度上是好的并且很有必要的（也可以是一個很好的學習過程），但作為軟件工程師，不斷地處理相同的底層實現(xiàn)細節(jié)對個人的開發(fā)生涯是有害的。

像 Spring 這種抽象框架的存在是有原因的，它將你從重復地手工勞作中解放出來，并允許你專注于更高層次的細節(jié) —— 領域對象和業(yè)務邏輯。因此，接受抽象。

下次面對特定問題時，首先進行快速搜索，確定解決該問題的庫是否已被集成到 Spring 中；

現(xiàn)在，你可能找到一個合適的現(xiàn)成解決方案。比如，一個很有用的庫，在本文的其他部分，我將在示例中使用 Project Lombok 注解。Lombok 被用作樣板代碼生成器，希望懶惰的開發(fā)人員在熟悉這個庫時不會遇到問題。

舉個例子，看看使用 Lombok 的 “標準 Java Bean” 是什么樣子的：如你所想，上述代碼被編譯為：但是，請注意，如果你打算在 IDE 中使用 Lombok，很可能需要安裝一個插件，可在 此處 找到 Intellij IDEA 版本的插件。

2、錯誤二：內(nèi)部結構 “泄露”

公開你的內(nèi)部結構，從來都不是一個好主意，因為它在服務設計中造成了不靈活性，從而促進了不好的編碼實踐?！靶孤丁?的內(nèi)部機制表現(xiàn)為使數(shù)據(jù)庫結構可以從某些 API 端點訪問。

例如，下面的 POJO（“Plain Old Java Object”）類表示數(shù)據(jù)庫中的一個表：

假設，存在一個端點，他需要訪問 TopTalentEntity 數(shù)據(jù)。返回 TopTalentEntity 實例可能很誘人，但更靈活的解決方案是創(chuàng)建一個新的類來表示 API 端點上的 TopTalentEntity 數(shù)據(jù)。

這樣，對數(shù)據(jù)庫后端進行更改將不需要在服務層進行任何額外的更改?？紤]下，在TopTalentEntity 中添加一個 “password” 字段來存儲數(shù)據(jù)庫中用戶密碼的 Hash 值 —— 如果沒有 TopTalentData 之類的連接器，忘記更改服務前端，將會意外地暴露一些不必要的秘密信息。

3、錯誤三：缺乏關注點分離

隨著程序規(guī)模的增長，逐漸地，代碼組織成為一個越來越重要的問題。諷刺的是，大多數(shù)好的軟件工程原則開始在規(guī)模上崩潰 —— 特別是在沒有太多考慮程序體系結構設計的情況下。

開發(fā)人員最常犯的一個錯誤就是混淆代碼關注點，這很容易做到！通常，打破 關注點分離 的是將新功能簡單地 “倒” 在現(xiàn)有類中。當然，這是一個很好的短期解決方案（對于初學者來說，它需要更少的輸入），但它也不可避免地會在將來成為一個問題，無論是在測試期間、維護期間還是介于兩者之間。

考慮下下面的控制器，它將從數(shù)據(jù)庫返回 TopTalentData。

這種層次結構的另一個優(yōu)點是，它允許我們通過檢查類名來確定將功能駐留在何處。此外，在測試期間，如果需要，我們可以很容易地用模擬實現(xiàn)來替換任何類。

4、錯誤四：缺乏異常處理或處理不當

一致性的主題并非是 Spring（或 Java）所獨有的，但仍然是處理 Spring 項目時需要考慮的一個重要方面。

雖然編碼風格可能存在爭議（通常團隊或整個公司內(nèi)部已達成一致），但擁有一個共同的標準最終會極大地提高生產(chǎn)力。對多人團隊尤為如此；一致性允許交流發(fā)生，而不需要花費很多資源在手把手交接上，也不需要就不同類的職責提供冗長的解釋。

考慮一個包含各種配置文件、服務和控制器的 Spring 項目。在命名時保持語義上的一致性，可以創(chuàng)建一個易于搜索的結構，任何新的開發(fā)人員都可以按照自己的方式管理代碼；例如，將 Config 后綴添加到配置類，服務層以 Service 結尾，以及控制器用 Controller 結尾。

與一致性主題密切相關，服務器端的錯誤處理值得特別強調。如果你曾經(jīng)不得不處理編寫很差的 API 的異常響應，那你可能知道原因 —— 正確解析異常會是一件痛苦的事情，而確定這些異常最初發(fā)生的原因則更為痛苦。

作為一名 API 開發(fā)者，理想情況下你希望覆蓋所有面向用戶的端點，并將他們轉換為常見的錯誤格式。這通常意味著有一個通用的錯誤代碼和描述，而不是逃避解決問題：a) 返回一個 “500 Internal Server Error”信息。b) 直接返回異常的堆棧信息給用戶。

（實際上，這些都應該不惜一切代價地去避免，因為除了客戶端難以處理以外，它還暴露了你的內(nèi)部信息）。例如，常見錯誤響應格式可能長這樣：

然而，上面的方法（除了構造很差以外）并不是一個真正 “干凈” 的解決辦法。我們正檢查不止一種類型的有效性（即 TopTalentData 不得為空，TopTalentData.name 不得為空，且 TopTalentData.name 為 10 個字符長度），以及在數(shù)據(jù)無效時拋出異常。

通過在 Spring 中集成 Hibernate validator，數(shù)據(jù)校驗可以更干凈地進行。讓我們首先重構 addTopTalent 方法來支持驗證：

7、錯誤七：（依舊）使用基于xml的配置

雖然之前版本的 Spring 需要 XML，但如今大部分配置均可通過 Java 代碼或注解來完成；XML 配置只是作為附加的不必要的樣板代碼。本文（及其附帶的 GitHub 倉庫）均使用注解來配置 Spring，Spring 知道應該連接哪些 Bean，因為待掃描的頂級包目錄已在 @SpringBootApplication 復合注解中做了聲明，如下所示：

假設你不希望在修改代碼時意外地對生產(chǎn)數(shù)據(jù)庫進行任何操作，因此將默認配置文件設為 dev 是很有意義的。

然后，在服務器上，你可以通過提供 -Dspring.profiles.active=prod 參數(shù)給 JVM 來手動覆蓋配置文件。另外，還可將操作系統(tǒng)的環(huán)境變量設置為所需的默認 profile。

9、錯誤九：無法接受依賴項注入

正確使用 Spring 的依賴注入意味著允許其通過掃描所有必須的配置類來將所有對象連接在一起；這對于解耦關系非常有用，也使測試變得更為容易，而不是通過類之間的緊耦合來做這樣的事情：

Misko Hevery 的 Google talk 深入解釋了依賴注入的 “為什么”，所以，讓我們看看它在實踐中是如何使用的。

在關注點分離（常見錯誤 #3）一節(jié)中，我們創(chuàng)建了一個服務和控制器類。假設我們想在 TopTalentService 行為正確的前提下測試控制器。我們可以通過提供一個單獨的配置類來插入一個模擬對象來代替實際的服務實現(xiàn)：

之后，我們就可以使用上下文配置將 Bean 注入到單元測試中。

10、錯誤十：缺乏測試，或測試不當

盡管單元測試的概念已經(jīng)存在很長時間了，但很多開發(fā)人員似乎要么 “忘記” 做這件事（特別是如果它不是 “必需” 的時候），要么只是在事后把它添加進來。

這顯然是不可取的，因為測試不僅應該驗證代碼的正確性，還應該作為程序在不同場景下應如何表現(xiàn)的文檔。在測試 Web 服務時，很少只進行 “純” 單元測試，因為通過 HTTP 進行通信通常需要調用 Spring 的 DispatcherServlet，并查看當收到一個實際的 HttpServletRequest 時會發(fā)生什么（使它成為一個 “集成” 測試，處理驗證、序列化等）。

REST Assured，一個用于簡化測試REST服務的 Java DSL，在 MockMVC 之上，已經(jīng)被證明提供了一個非常優(yōu)雅的解決方案。考慮以下帶有依賴項注入的代碼片段：

SampleUnitTestConfig 類將 TopTalentService 的模擬實現(xiàn)連接到 TopTalentController 中，而所有的其他類都是通過掃描應用類所在包的下級包目錄來推斷出的標準配置。RestAssuredMockMvc 只是用來設置一個輕量級環(huán)境，并向 /toptal/get 端點發(fā)送一個 GET請求。