Spring 可以說是很流行的 Java 框架之一，也是一只需要馴服的強大野獸。雖然它的基本概念相當容易掌握，但成為一名強大的 Spring 開發者仍需要很多時間和努力。

[[272146]]

在本文中，我們將介紹 Spring 中一些常見的錯誤，特別是面向 Web 應用程序和 Spring Boot。正如 Spring Boot 官網 所說，Spring Boot 對應該如何構建 Production-Ready 的應用保持著 相當固執的觀點，本文將嘗試模仿這種觀點，并提供一些技巧的概述，這些技巧將很好地融入標準 Spring Boot 的 web 應用程序開發中去。

如果你對 Spring Boot 還不是很熟悉，但仍想嘗試下接下來提到的一些內容，我也為本文創建了一個 GitHub 倉庫。如果你在閱讀過程中感到困惑，我建議把代碼 clone 下來，并在本地電腦上使用這些代碼。

1. 常見錯誤一：太過關注底層

我們正在解決這個常見錯誤，是因為 “非我所創” 綜合癥在軟件開發領域很是常見。癥狀包括經常重寫一些常見的代碼，很多開發人員都有這種癥狀。

雖然理解特定庫的內部結構及其實現，在很大程度上是好的并且很有必要的(也可以是一個很好的學習過程)，但作為軟件工程師，不斷地處理相同的底層實現細節對個人的開發生涯是有害的。像 Spring 這種抽象框架的存在是有原因的，它將你從重復地手工勞作中解放出來，并允許你專注于更高層次的細節 —— 領域對象和業務邏輯。

因此，接受抽象。下次面對特定問題時，首先進行快速搜索，確定解決該問題的庫是否已被集成到 Spring 中;現在，你可能找到一個合適的現成解決方案。比如，一個很有用的庫，在本文的其他部分，我將在示例中使用 Project Lombok 注解。Lombok 被用作樣板代碼生成器，希望懶惰的開發人員在熟悉這個庫時不會遇到問題。舉個例子，看看使用 Lombok 的 “標準 Java Bean” 是什么樣子的：

@Getter 
@Setter 
@NoArgsConstructor 
public class Bean implements Serializable { 
 int firstBeanProperty; 
 String secondBeanProperty; 
}復制代碼 

如你所想，上述代碼被編譯為：

public class Bean implements Serializable { 
 private int firstBeanProperty; 
 private String secondBeanProperty; 
 public int getFirstBeanProperty() { 
 return this.firstBeanProperty; 
 } 
 public String getSecondBeanProperty() { 
 return this.secondBeanProperty; 
 } 
 public void setFirstBeanProperty(int firstBeanProperty) { 
 this.firstBeanProperty = firstBeanProperty; 
 } 
 public void setSecondBeanProperty(String secondBeanProperty) { 
 this.secondBeanProperty = secondBeanProperty; 
 } 
 public Bean() { 
 } 
}復制代碼 

但是，請注意，如果你打算在 IDE 中使用 Lombok，很可能需要安裝一個插件，可在 此處 找到 Intellij IDEA 版本的插件。

2. 常見錯誤二：內部結構 “泄露”

公開你的內部結構，從來都不是一個好主意，因為它在服務設計中造成了不靈活性，從而促進了不好的編碼實踐。“泄露” 的內部機制表現為使數據庫結構可以從某些 API 端點訪問。例如，下面的 POJO(“Plain Old Java Object”)類表示數據庫中的一個表：

@Entity 
@NoArgsConstructor 
@Getter 
public class TopTalentEntity { 
 @Id 
 @GeneratedValue 
 private Integer id; 
 @Column 
 private String name; 
 public TopTalentEntity(String name) { 
 this.name = name; 
 } 
}復制代碼 

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

@AllArgsConstructor 
@NoArgsConstructor 
@Getter 
public class TopTalentData { 
 private String name; 
}復制代碼 

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

3. 常見錯誤三：缺乏關注點分離

隨著程序規模的增長，逐漸地，代碼組織成為一個越來越重要的問題。諷刺的是，大多數好的軟件工程原則開始在規模上崩潰 —— 特別是在沒有太多考慮程序體系結構設計的情況下。開發人員最常犯的一個錯誤就是混淆代碼關注點，這很容易做到!

通常，打破 關注點分離 的是將新功能簡單地 “倒” 在現有類中。當然，這是一個很好的短期解決方案(對于初學者來說，它需要更少的輸入)，但它也不可避免地會在將來成為一個問題，無論是在測試期間、維護期間還是介于兩者之間。考慮下下面的控制器，它將從數據庫返回 TopTalentData。

@RestController 
public class TopTalentController { 
 private final TopTalentRepository topTalentRepository; 
 @RequestMapping("/toptal/get") 
 public List<TopTalentData> getTopTalent() { 
 return topTalentRepository.findAll() 
 .stream() 
 .map(this::entityToData) 
 .collect(Collectors.toList()); 
 } 
 private TopTalentData entityToData(TopTalentEntity topTalentEntity) { 
 return new TopTalentData(topTalentEntity.getName()); 
 } 
}復制代碼 

起初，這段代碼似乎沒什么特別的問題;它提供了一個從 TopTalentEntity 實例檢索出來的 TopTalentData 的 List。然而，仔細觀察下，我們可以看到 TopTalentController 實際上在此做了些事情;也就是說，它將請求映射到特定端點，從數據庫檢索數據，并將從 TopTalentRepository 接收的實體轉換為另一種格式。一個“更干凈” 的解決方案是將這些關注點分離到他們自己的類中。看起來可能是這個樣子的：

@RestController 
@RequestMapping("/toptal") 
@AllArgsConstructor 
public class TopTalentController { 
 private final TopTalentService topTalentService; 
 @RequestMapping("/get") 
 public List<TopTalentData> getTopTalent() { 
 return topTalentService.getTopTalent(); 
 } 
} 
@AllArgsConstructor 
@Service 
public class TopTalentService { 
 private final TopTalentRepository topTalentRepository; 
 private final TopTalentEntityConverter topTalentEntityConverter; 
 public List<TopTalentData> getTopTalent() { 
 return topTalentRepository.findAll() 
 .stream() 
 .map(topTalentEntityConverter::toResponse) 
 .collect(Collectors.toList()); 
 } 
} 
@Component 
public class TopTalentEntityConverter { 
 public TopTalentData toResponse(TopTalentEntity topTalentEntity) { 
 return new TopTalentData(topTalentEntity.getName()); 
 } 
}復制代碼 

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

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

一致性的主題并非是 Spring(或 Java)所獨有的，但仍然是處理 Spring 項目時需要考慮的一個重要方面。雖然編碼風格可能存在爭議(通常團隊或整個公司內部已達成一致)，但擁有一個共同的標準最終會極大地提高生產力。對多人團隊尤為如此;一致性允許交流發生，而不需要花費很多資源在手把手交接上，也不需要就不同類的職責提供冗長的解釋。

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

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

作為一名 API 開發者，理想情況下你希望覆蓋所有面向用戶的端點，并將他們轉換為常見的錯誤格式。這通常意味著有一個通用的錯誤代碼和描述，而不是逃避解決問題：a) 返回一個 “500 Internal Server Error”信息。b) 直接返回異常的堆棧信息給用戶。(實際上，這些都應該不惜一切代價地去避免，因為除了客戶端難以處理以外，它還暴露了你的內部信息)。

例如，常見錯誤響應格式可能長這樣：

@Value 
public class ErrorResponse { 
 private Integer errorCode; 
 private String errorMessage; 
}復制代碼 

與此類似的事情在大多數流行的 API 中也經常遇到，由于可以容易且系統地記錄，效果往往很不錯。將異常轉換為這種格式可以通過向方法提供 @ExceptionHandler 注解來完成(注解案例可見于第六章)。

5. 常見錯誤五：多線程處理不當

不管是桌面應用還是 Web 應用，無論是 Spring 還是 No Spring，多線程都是很難破解的。由并行執行程序所引起的問題是令人毛骨悚然且難以捉摸的，而且常常難以調試 —— 實際上，由于問題的本質，一旦你意識到你正在處理一個并行執行問題，你可能就不得不完全放棄調試器了，并 “手動” 檢查代碼，直到找到根本上的錯誤原因。不幸的是，這類問題并沒有千篇一律的解決方案;根據具體場景來評估情況，然后從你認為最好的角度來解決問題。

當然，理想情況下，你也希望完全避免多線程錯誤。同樣，不存在那種一刀切的方法，但這有一些調試和防止多線程錯誤的實際考慮因素：

5.1. 避免全局狀態

首先，牢記 “全局狀態” 問題。如果你正創建一個多線程應用，那么應該密切關注任何可能全局修改的內容，如果可能的話，將他們全部刪掉。如果某個全局變量有必須保持可修改的原因，請仔細使用 synchronization，并對程序性能進行跟蹤，以確定沒有因為新引入的等待時間而導致系統性能降低。

5.2. 避免可變性

這點直接來自于 函數式編程，并且適用于 OOP，聲明應該避免類和狀態的改變。簡而言之，這意味著放棄 setter 方法，并在所有模型類上擁有私有的 final 字段。它們的值唯一發生變化的時間是在構造期間。這樣，你可以確定不會出現爭用問題，且訪問對象屬性將始終提供正確的值。

5.3. 記錄關鍵數據

評估你的程序可能會在何處發生異常，并預先記錄所有關鍵數據。如果發生錯誤，你將很高興可以得到信息說明收到了哪些請求，并可更好地了解你的應用程序為什么會出現錯誤。需要再次注意的是，日志記錄引入了額外的文件 I/O，可能會嚴重影響應用的性能，因此請不要濫用日志。

5.4. 復用現存實現

每當你需要創建自己的線程時(例如：向不同的服務發出異步請求)，復用現有的安全實現來代替創建自己的解決方案。這在很大程度上意味著要使用 ExecutorServices 和 Java 8 簡潔的函數式 CompletableFutures 來創建線程。Spring 還允許通過 DeferredResult 類來進行異步請求處理。

6. 常見錯誤六：不使用基于注解的驗證

假設我們之前的 TopTalent 服務需要一個端點來添加新的 TopTalent。此外，假設基于某些原因，每個新名詞都需要為 10 個字符長度。執行此操作的一種方法可能如下：

@RequestMapping("/put") 
public void addTopTalent(@RequestBody TopTalentData topTalentData) { 
 boolean nameNonExistentOrHasInvalidLength = 
 Optional.ofNullable(topTalentData) 
 .map(TopTalentData::getName) 
 .map(name -> name.length() == 10) 
 .orElse(true); 
 if (nameNonExistentOrInvalidLength) { 
 // throw some exception 
 } 
 topTalentService.addTopTalent(topTalentData); 
}復制代碼 

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

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

@RequestMapping("/put") 
public void addTopTalent(@Valid @NotNull @RequestBody TopTalentData topTalentData) { 
 topTalentService.addTopTalent(topTalentData); 
} 
@ExceptionHandler 
@ResponseStatus(HttpStatus.BAD_REQUEST) 
public ErrorResponse handleInvalidTopTalentDataException(MethodArgumentNotValidException methodArgumentNotValidException) { 
 // handle validation exception 
}復制代碼 

此外，我們還必須指出我們想要在 TopTalentData 類中驗證什么屬性：

public class TopTalentData { 
 @Length(min = 10, max = 10) 
 @NotNull 
 private String name; 
}復制代碼 

現在，Spring 將在調用方法之前攔截其請求并對參數進行驗證 —— 無需使用額外的手工測試。

另一種實現相同功能的方法是創建我們自己的注解。雖然你通常只在需要超出 Hibernate的內置約束集 時才使用自定義注解，本例中，我們假設 @Length 不存在。你可以創建兩個額外的類來驗證字符串長度，一個用于驗證，一個用于對屬性進行注解：

@Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER}) 
@Retention(RetentionPolicy.RUNTIME) 
@Documented 
@Constraint(validatedBy = { MyAnnotationValidator.class }) 
public @interface MyAnnotation { 
 String message() default "String length does not match expected"; 
 Class<?>[] groups() default {}; 
 Class<? extends Payload>[] payload() default {}; 
 int value(); 
} 
@Component 
public class MyAnnotationValidator implements ConstraintValidator<MyAnnotation, String> { 
 private int expectedLength; 
 @Override 
 public void initialize(MyAnnotation myAnnotation) { 
 this.expectedLength = myAnnotation.value(); 
 } 
 @Override 
 public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) { 
 return s == null || s.length() == this.expectedLength; 
 } 
}復制代碼 

請注意，這些情況下，關注點分離的最佳實踐要求在屬性為 null 時，將其標記為有效(isValid 方法中的 s == null)，如果這是屬性的附加要求，則使用 @NotNull 注解。

public class TopTalentData { 
 @MyAnnotation(value = 10) 
 @NotNull 
 private String name; 
}復制代碼 

7. 常見錯誤七：(依舊)使用基于xml的配置

雖然之前版本的 Spring 需要 XML，但如今大部分配置均可通過 Java 代碼或注解來完成;XML 配置只是作為附加的不必要的樣板代碼。

本文(及其附帶的 GitHub 倉庫)均使用注解來配置 Spring，Spring 知道應該連接哪些 Bean，因為待掃描的頂級包目錄已在 @SpringBootApplication 復合注解中做了聲明，如下所示：

@SpringBootApplication 
public class Application { 
 public static void main(String[] args) { 
 SpringApplication.run(Application.class, args); 
 } 
}復制代碼 

復合注解(可通過 Spring 文檔 了解更多信息)只是向 Spring 提示應該掃描哪些包來檢索 Bean。在我們的案例中，這意味著這個頂級包 (co.kukurin)將用于檢索：

• @Component (TopTalentConverter, MyAnnotationValidator)
• @RestController (TopTalentController)
• @Repository (TopTalentRepository)
• @Service (TopTalentService) 類

如果我們有任何額外的 @Configuration 注解類，它們也會檢查基于 Java 的配置。

8. 常見錯誤八：忽略 profile

在服務端開發中，經常遇到的一個問題是區分不同的配置類型，通常是生產配置和開發配置。在每次從測試切換到部署應用程序時，不要手動替換各種配置項，更有效的方法是使用 profile。

考慮這么一種情況：你正在使用內存數據庫進行本地開發，而在生產環境中使用 MySQL 數據庫。本質上，這意味著你需要使用不同的 URL 和 (希望如此) 不同的憑證來訪問這兩者。讓我們看看可以如何做到這兩個不同的配置文件：

8.1. APPLICATION.YAML 文件

# set default profile to 'dev' 
spring.profiles.active: dev 
# production database details 
spring.datasource.url: 'jdbc:mysql://localhost:3306/toptal' 
spring.datasource.username: root 
spring.datasource.password:復制代碼 

8.2. APPLICATION-DEV.YAML 文件

spring.datasource.url: 'jdbc:h2:mem:' 
spring.datasource.platform: h2復制代碼 

假設你不希望在修改代碼時意外地對生產數據庫進行任何操作，因此將默認配置文件設為 dev 是很有意義的。然后，在服務器上，你可以通過提供 -Dspring.profiles.active=prod 參數給 JVM 來手動覆蓋配置文件。另外，還可將操作系統的環境變量設置為所需的默認 profile。

9. 常見錯誤九：無法接受依賴項注入

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

public class TopTalentController { 
 private final TopTalentService topTalentService; 
 public TopTalentController() { 
 this.topTalentService = new TopTalentService(); 
 } 
}復制代碼 

我們讓 Spring 為我們做連接：

public class TopTalentController { 
 private final TopTalentService topTalentService; 
 public TopTalentController(TopTalentService topTalentService) { 
 this.topTalentService = topTalentService; 
 } 
}復制代碼 

Misko Hevery 的 Google talk 深入解釋了依賴注入的 “為什么”，所以，讓我們看看它在實踐中是如何使用的。在關注點分離(常見錯誤 #3)一節中，我們創建了一個服務和控制器類。假設我們想在 TopTalentService 行為正確的前提下測試控制器。我們可以通過提供一個單獨的配置類來插入一個模擬對象來代替實際的服務實現：

@Configuration 
public class SampleUnitTestConfig { 
 @Bean 
 public TopTalentService topTalentService() { 
 TopTalentService topTalentService = Mockito.mock(TopTalentService.class); 
 Mockito.when(topTalentService.getTopTalent()).thenReturn( 
 Stream.of("Mary", "Joel").map(TopTalentData::new).collect(Collectors.toList())); 
 return topTalentService; 
 } 
}復制代碼 

然后，我們可以通過告訴 Spring 使用 SampleUnitTestConfig 作為它的配置類來注入模擬對象：

@ContextConfiguration(classes = { SampleUnitTestConfig.class })復制代碼 

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

10. 常見錯誤十：缺乏測試，或測試不當

盡管單元測試的概念已經存在很長時間了，但很多開發人員似乎要么 “忘記” 做這件事(特別是如果它不是 “必需” 的時候)，要么只是在事后把它添加進來。這顯然是不可取的，因為測試不僅應該驗證代碼的正確性，還應該作為程序在不同場景下應如何表現的文檔。

在測試 Web 服務時，很少只進行 “純” 單元測試，因為通過 HTTP 進行通信通常需要調用 Spring 的 DispatcherServlet，并查看當收到一個實際的 HttpServletRequest 時會發生什么(使它成為一個 “集成” 測試，處理驗證、序列化等)。REST Assured，一個用于簡化測試REST服務的 Java DSL，在 MockMVC 之上，已經被證明提供了一個非常優雅的解決方案。考慮以下帶有依賴項注入的代碼片段：

@RunWith(SpringJUnit4ClassRunner.class) 
@ContextConfiguration(classes = { 
 Application.class, 
 SampleUnitTestConfig.class 
}) 
public class RestAssuredTestDemonstration { 
 @Autowired 
 private TopTalentController topTalentController; 
 @Test 
 public void shouldGetMaryAndJoel() throws Exception { 
 // given 
 MockMvcRequestSpecification givenRestAssuredSpecification = RestAssuredMockMvc.given() 
 .standaloneSetup(topTalentController); 
 // when 
 MockMvcResponse response = givenRestAssuredSpecification.when().get("/toptal/get"); 
 // then 
 response.then().statusCode(200); 
 response.then().body("name", hasItems("Mary", "Joel")); 
 } 
}復制代碼 

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

11. 成為 Spring 大師

Spring 是一個功能強大的框架，很容易上手，但需要一些投入和時間才可以完全掌握。長遠來看，花時間熟悉框架肯定會提高你的生產力，并最終助你寫出更干凈的代碼，成為更好的開發人員。

想尋找更多資源，Spring In Action 是一本涵蓋了很多 Spring 核心主題的優秀實戰書籍。