DTO
數據傳輸我們應該使用DTO對象作爲傳輸對象,這是我們所約定的,因爲很長時間我一直都在做移動端api設計的工作,有很多人告訴我,他們認爲只有給手機端傳輸數據的時候(input or output),這些對象成爲DTO對象。請注意!這種理解是錯誤的,只要是用於網絡傳輸的對象,我們都認爲他們可以當做是DTO對象,比如電商平臺中,用戶進行下單,下單後的數據,訂單會發到OMS 或者 ERP系統,這些對接的返回值以及入參也叫DTO對象。
我們約定某對象如果是DTO對象,就將名稱改爲XXDTO,比如訂單下發OMS:OMSOrderInputDTO。
DTO轉化
正如我們所知,DTO爲系統與外界交互的模型對象,那麼肯定會有一個步驟是將DTO對象轉化爲BO對象或者是普通的entity對象,讓service層去處理。
場景
比如添加會員操作,由於用於演示,我只考慮用戶的一些簡單數據,當後臺管理員點擊添加用戶時,只需要傳過來用戶的姓名和年齡就可以了,後端接受到數據後,將添加創建時間和更新時間和默認密碼三個字段,然後保存數據庫。
@RequestMapping("/v1/api/user")
@RestController
public class UserApi {
@Autowired
private UserService userService;
@PostMapping
public User addUser(UserInputDTO userInputDTO){
User user = new User();
user.setUsername(userInputDTO.getUsername());
user.setAge(userInputDTO.getAge());
return userService.addUser(user);
}
}
我們只關注一下上述代碼中的轉化代碼,其他內容請忽略:- User user = new User();
- user.setUsername(userInputDTO.getUsername());
- user.setAge(userInputDTO.getAge());
請使用工具
上邊的代碼,從邏輯上講,是沒有問題的,只是這種寫法讓我很厭煩,例子中只有兩個字段,如果有20個字段,我們要如何做呢? 一個一個進行set數據嗎?當然,如果你這麼做了,肯定不會有什麼問題,但是,這肯定不是一個最優的做法。
網上有很多工具,支持淺拷貝或深拷貝的Utils. 舉個例子,我們可以使用org.springframework.beans.BeanUtils#copyProperties對代碼進行重構和優化:
- @PostMapping
- public User addUser(UserInputDTO userInputDTO){
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return userService.addUser(user);
- }
轉化的語義
上邊的轉化過程,讀者看後肯定覺得優雅很多,但是我們再寫java代碼時,更多的需要考慮語義的操作,再看上邊的代碼:
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- @PostMapping
- public User addUser(UserInputDTO userInputDTO){
- User user = convertFor(userInputDTO);
- return userService.addUser(user);
- }
- private User convertFor(UserInputDTO userInputDTO){
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return user;
- }
- User user = convertFor(userInputDTO);
- return userService.addUser(user);
這兩段代碼都沒有暴露實現,都是在講如何在同一個方法中,做一組相同層次的語義操作,而不是暴露具體的實現。如上所述,是一種重構方式,讀者可以參考Martin Fowler的《Refactoring Imporving the Design of Existing Code》(重構 改善既有代碼的設計) 這本書中的Extract Method重構方式。
抽象接口定義
當實際工作中,完成了幾個api的DTO轉化時,我們會發現,這樣的操作有很多很多,那麼應該定義好一個接口,讓所有這樣的操作都有規則的進行。
如果接口被定義以後,那麼convertFor這個方法的語義將產生變化,他將是一個實現類。
看一下抽象後的接口:
- public interface DTOConvert<S,T> {
- T convert(S s);
- }
雖然這個接口很簡單,但是這裏告訴我們一個事情,要去使用泛型,如果你是一個優秀的java程序員,請爲你想做的抽象接口,做好泛型吧。我們再來看接口實現:
- public class UserInputDTOConvert implements DTOConvert {
- @Override
- public User convert(UserInputDTO userInputDTO) {
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return user;
- }
- }
- @RequestMapping("/v1/api/user")
- @RestController
- public class UserApi {
- @Autowired
- private UserService userService;
- @PostMapping
- public User addUser(UserInputDTO userInputDTO){
- User user = new UserInputDTOConvert().convert(userInputDTO);
- return userService.addUser(user);
- }
- }
review code
如果你是一個優秀的java程序員,我相信你應該和我一樣,已經數次重複review過自己的代碼很多次了。
我們再看這個保存用戶的例子,你將發現,api中返回值是有些問題的,問題就在於不應該直接返回User實體,因爲如果這樣的話,就暴露了太多實體相關的信息,這樣的返回值是不安全的,所以我們更應該返回一個DTO對象,我們可稱它爲UserOutputDTO:
- @PostMapping
- public UserOutputDTO addUser(UserInputDTO userInputDTO){
- User user = new UserInputDTOConvert().convert(userInputDTO);
- User saveUserResult = userService.addUser(user);
- UserOutputDTO result = new UserOutDTOConvert().convertToUser(saveUserResult);
- return result;
- }
這樣你的api才更健全。不知道在看完這段代碼之後,讀者有是否發現還有其他問題的存在,作爲一個優秀的java程序員,請看一下這段我們剛剛抽象完的代碼:
User user = new UserInputDTOConvert().convert(userInputDTO);
你會發現,new這樣一個DTO轉化對象是沒有必要的,而且每一個轉化對象都是由在遇到DTO轉化的時候纔會出現,那我們應該考慮一下,是否可以將這個類和DTO進行聚合呢,看一下我的聚合結果:
public class UserInputDTO {
private String username;
private int age;
- public String getUsername() {
- return username;
- }
- public void setUsername(String username) {
- this.username = username;
- }
- public int getAge() {
- return age;
- }
- public void setAge(int age) {
- this.age = age;
- }
- public User convertToUser(){
- UserInputDTOConvert userInputDTOConvert = new UserInputDTOConvert();
- User convert = userInputDTOConvert.convert(this);
- return convert;
- }
- private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> {
- @Override
- public User convert(UserInputDTO userInputDTO) {
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return user;
- }
- }
然後api中的轉化則由:
User user = new UserInputDTOConvert().convert(userInputDTO);
User saveUserResult = userService.addUser(user);
變成了:
User user = userInputDTO.convertToUser();
User saveUserResult = userService.addUser(user);
我們再DTO對象中添加了轉化的行爲,我相信這樣的操作可以讓代碼的可讀性變得更強,並且是符合語義的。
再查工具類
再來看DTO內部轉化的代碼,它實現了我們自己定義的DTOConvert接口,但是這樣真的就沒有問題,不需要再思考了嗎?
我覺得並不是,對於Convert這種轉化語義來講,很多工具類中都有這樣的定義,這中Convert並不是業務級別上的接口定義,它只是用於普通bean之間轉化屬性值的普通意義上的接口定義,所以我們應該更多的去讀其他含有Convert轉化語義的代碼。
我仔細閱讀了一下GUAVA的源碼,發現了com.google.common.base.Convert這樣的定義:
- public abstract class Converter<A, B> implements Function<A, B> {
- protected abstract B doForward(A a);
- protected abstract A doBackward(B b);
- //其他略
- }
- private static class UserInputDTOConvert implements DTOConvert<UserInputDTO,User> {
- @Override
- public User convert(UserInputDTO userInputDTO) {
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return user;
- }
- }
修改後:
- private static class UserInputDTOConvert extends Converter<UserInputDTO, User> {
- @Override
- protected User doForward(UserInputDTO userInputDTO) {
- User user = new User();
- BeanUtils.copyProperties(userInputDTO,user);
- return user;
- }
- @Override
- protected UserInputDTO doBackward(User user) {
- UserInputDTO userInputDTO = new UserInputDTO();
- BeanUtils.copyProperties(user,userInputDTO);
- return userInputDTO;
- }
- }
看了這部分代碼以後,你可能會問,那逆向轉化會有什麼用呢?其實我們有很多小的業務需求中,入參和出參是一樣的,那麼我們變可以輕鬆的進行轉化,我將上邊所提到的UserInputDTO和UserOutputDTO都轉成UserDTO展示給大家:
DTO:
- public class UserDTO {
- private String username;
- private int age;
- public String getUsername() {
- return username;
- }
- public void setUsername(String username) {
- this.username = username;
- }
- public int getAge() {
- return age;
- }
- public void setAge(int age) {
- this.age = age;
- }
- public User convertToUser(){
- UserDTOConvert userDTOConvert = new UserDTOConvert();
- User convert = userDTOConvert.convert(this);
- return convert;
- }
- public UserDTO convertFor(User user){
- UserDTOConvert userDTOConvert = new UserDTOConvert();
- UserDTO convert = userDTOConvert.reverse().convert(user);
- return convert;
- }
- private static class UserDTOConvert extends Converter<UserDTO, User> {
- @Override
- protected User doForward(UserDTO userDTO) {
- User user = new User();
- BeanUtils.copyProperties(userDTO,user);
- return user;
- }
- @Override
- protected UserDTO doBackward(User user) {
- UserDTO userDTO = new UserDTO();
- BeanUtils.copyProperties(user,userDTO);
- return userDTO;
- }
- }
- }
- @PostMapping
- public UserDTO addUser(UserDTO userDTO){
- User user = userDTO.convertToUser();
- User saveResultUser = userService.addUser(user);
- UserDTO result = userDTO.convertFor(saveResultUser);
- return result;
- }
- private static class UserDTOConvert extends Converter<UserDTO, User> {
- @Override
- protected User doForward(UserDTO userDTO) {
- User user = new User();
- BeanUtils.copyProperties(userDTO,user);
- return user;
- }
- @Override
- protected UserDTO doBackward(User user) {
- throw new AssertionError("不支持逆向轉化方法!");
- }
- }
看一下doBackward方法,直接拋出了一個斷言異常,而不是業務異常,這段代碼告訴代碼的調用者,這個方法不是準你調用的,如果你調用,我就”斷言”你調用錯誤了。