使用 Spring Framework 时常犯的十大错误

通常，打破 关注点分离 的是将新功能简单地 “倒” 在现有类中。当然，这是一个很好的短期解决方案(对于初学者来说，它需要更少的输入)，但它也不可避免地会在将来成为一个问题，无论是在测试期间、维护期间还是介于两者之间。考虑下下面的控制器，它将从数据库返回 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. 常见错误五：多线程处理不当

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!