week.ioAndroid android

[架构向] 谈Android中DTO -> VO的重要性

2016-11-21  本文已影响3354人  YoKey

标题虽然仅指DTO->VO，其实更准确的说，应该是各种DTO、DAO等都需要转VO ，本文仅以DTO为例。

不管你在使用MVC，MVP还是MVVM，这篇文章会让你的M层赋有更佳的职能。

Clean架构的Mapper

在去年尝试Android-CleanArchitecture时，data模块和presentation模块里有2个Mapper类，用于把UserEntity转成User，以及User转成UserModel，最终V层使用的是UserModel对象。

当时很难理解的是为何一个User要转来转去，现在回头来看，对象的映射转换是一个良好的架构所必需的要素，不管是MVC，MVP还是MVVM。

VO 、DTO在Android

** 1、 VO **

value object值对象
ViewObject表现层对象

主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。

Android中即：UI层的View需要的对象。

**2、 DTO **

Data Transfer Object数据传输对象

指用于展示层与服务层之间的数据传输对象。

Android中即：接口中返回的数据结构JSON转换后的对象。

痛点

可能我们一般会忽略VO层，只有DTO层，即：View展示的Model对象和接口返回的Model是同一个对象，即DTO。

这样做看起来，省略了VO层也没什么问题，但是我告诉你，在开发过程的所遇到的一些痛点，都和缺少VO层脱离不了关系：

1、你是否经常担心View在使用Model时，Model或Model的某个字段为null?

什么？你说你在C / P层或者domain中进行了安全性的null校验？

但是你不觉得在C／P或domain层处理这种安全校验是一种“脏代码”吗？ 这样会加重C／P或domain层的负担，降低其可读性。

这种 “糙活” 应该是由更上游的M层来处理！

2、接口返回的数据结构或字段突然变更了！！

这太常见了！！需求变更等等因素都会引起这个问题。

你在改变DTO字段的同时，还要同时改变所以使用该DTO的View处的代码！

3、接口返回的数据结构不是我想要的啊！！！

因为后台人员的各种原因，导致接口返回的数据结构根本不是我们想要的，而你在和后台撕逼失败后，你是否在苦恼该如何处理这蛋疼的数据结构？

更痛苦的是这条和第2条一并出现时，我想你一定是这样的：

4、接口文档迟迟没有！！

在开发过程中，你的View已经写好，但是接口文档迟迟还没有给出，即使给出，变更的几率也会非常大！

即使你们有接口评审这个环节，但是仍不能100%保证最后的数据结构和字段名称都是像接口评审时敲定的那样！

上述的4个痛点，我相信在你的开发过程中经常会遇到，而解决之道在于：

你需要添加一个VO层，以及DTO->VO层的映射Mapper ！

一个映射例子

有这样一个接口:

@GET
Observable<UserListDTO> getUserList()

public final class UserListDTO {
   public int version;  // 一个与View无关的属性
   public List<UserDTO> userList;
  
   static class UserDTO {
      public String uid;
      public String user_name;
      public String gender;
   }
}

你需要拿到UserList然后展现到RecyclerView上。

但是对于View层来说：

VO层

public final class User{
   public String id;
   public String name;
   public boolean isMale;
}

Mapper

public interface Mapper<T>{
   T transform();
}

转换过程：

public final class UserListDTO implements Mapper<List<User>>{
   public int version;
   public List<UserListDTO.UserDTO> userList;
  
   @Override
   public List<User> transform() {
      List<User> list = new ArrayList<>();
      for(UserDTO dto : userList){
         list.add(dto.transform);
      }
      return list;
  }
  
  private static class UserDTO implements Mapper<User>{
     public String uid;
     public String user_name;
     public String gender;
    
     @Override
    public User transform() {
       User user = new User();
       user.id = uid;
       user.name = user_name == null ? "未知" : user_name;
       isMale = "0".equals(gender);
       return user;
     }
  }
}

使用

Api.getService().getUserList()  // Retrofit
                ....
                .map(new Func1<UserListDTO, List<User>() {
                    @Override
                    public String call(UserListDTO dto) {
                        return dto.transform;
                    }
                })
                .subscribe(...) // 将List<User>指派给V层

如何解决痛点的？

@Override 
public User transform() {
     ...
     user.name = userName;
}

VO以及View使用VO的地方则无需更改！

PS: 上述只是一个简单例子，实际场景中，不符合预期的数据结构可能要复杂很多

M层还可以做更多：

假如现在的需求是，User的性别不同，在RecyclerView中显示的View就不同，即属于不同的ItemType，你可能会把这个判断写在：

 @Override
 public int getItemViewType(int position) {
    User user = mDatas.get(position);
    return user.male ? 0 : 1;
 }

虽然看起来没多少代码，但是实际情况我们遇到的需求往往会很复杂，getItemViewType()里需要写不少逻辑代码，这时你的Adapter里充斥了一些“脏代码”。

V层应该专注V应该做的事，而不是数据的处理、业务逻辑！

请放到Mapper里做：

public final class User{
   ...
   public int itemType;
}



private static class UserDTO implements Mapper<User>{
     @Override
    public User transform() {
        ...
        user.itemType = user.isMale ? 0 : 1;
        return user;
    }
  }

总结：

PS：文中转换的方式是构建Mapper接口，使用起来很方便。
你也可以像Android-CleanArchitecture一样创建独立的Mapper类：在Mapper类进行transform，优点是可以保持DTO与VO的干净和独立；

上一篇下一篇

猜你喜欢

热点阅读