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

标题虽然仅指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条一并出现时,我想你一定是这样的:

《[架构向] 谈Android中DTO -> VO的重要性》” /></p><h4>4、接口文档迟迟没有!!</h4><p>在开发过程中,你的View已经写好,但是接口文档迟迟还没有给出,即使给出,变更的几率也会非常大!</p><p>即使你们有<strong>接口评审</strong>这个环节,但是仍不能100%保证最后的数据结构和字段名称都是像<strong>接口评审</strong>时敲定的那样!</p><p>上述的4个痛点,我相信在你的开发过程中经常会遇到,而解决之道在于:</p><p><strong>你需要添加一个VO层,以及DTO->VO层的映射Mapper !</strong></p><h2>一个映射例子</h2><p>有这样一个接口:</p><pre><code>@GET
Observable<UserListDTO> getUserList()
</code></pre><pre><code>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;
   }
}
</code></pre><p>你需要拿到UserList然后展现到RecyclerView上。</p><p>但是对于View层来说:</p><ul><li>我不想知道你的<code>version</code>是干嘛的</li><li>我只需要一个List<User>,User里有<code>id</code>,<code>name</code>以及<code>男or女</code>即可</li><li>我不想要什么<code>uid</code>,<code>user_name</code>,<code>gender</code>等这样后台强加给我的命名或数据类型(即便我们有GSON的<code>@SerializedName</code>注解)</li><li>更重要的是我不想拿到一个为<code>null</code>的userList,</li></ul><h4>VO层</h4><pre><code>public final class User{
   public String id;
   public String name;
   public boolean isMale;
}
</code></pre><h4>Mapper</h4><pre><code>public interface Mapper<T>{
   T transform();
}
</code></pre><p>转换过程:</p><pre><code>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 ?

使用

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

如何解决痛点的?

  • 痛点1:M或M的属性为null?
    V层不用担心会不会拿到的是null,因为已经在DTO的transform()进行安全处理了,在null时也会返回size=0的List<User>。
    同时对User中的name也进行了安全性检查。
  • 痛点2:接口返回的数据结构或字段突然变更
    使用这种Mapper之后,大多数情况,你只需要更改DTO里的transform()的实现即可。

    比如UserDTO的user_name要更改为userName,或者gender不再是”0″为男性等等更改,你只需要在DTO里做如下更改即可:

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

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

  • 痛点3:接口返回的数据结构不是我想要的?
    没关系,把它转成我们想要的VO对象即可,上文中gender对View来说只需要是男or女即可,不需要知道“gender的值为0时是男性”这种业务逻辑。

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

  • 痛点4:接口文档迟迟没有
    真实开发过程中,我们会先拿到设计稿,有了设计稿后台才开始写接口文档。
    但是如果我们进度太超前,或者某种原因后台人员投入时间过晚,此时我们的接口文档拿到会比较晚。

    如果我们就这样等着后台人员岂不很蠢?!

    好好利用VO把!其实我们根据设计稿就可以明确知道,各个页面所需要的数据模型,此时只要创建一个我们自己需要的VO对象,而View使用该VO展现即可。
    在真正的DTO出来之前,你可以用VO来mock数据、接口;一旦DTO出来,只要在DTO内做一个Mapper即可,VO以及View一般不需要更改!

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;
    }
  }

总结:

  • 从实用角度出发:Mapper可以让你的开发过程更高效,更从容面对需求变更、接口变更等外在因素。

  • 从架构角度出发:Mapper的出现可以让M层可以承担更多的职责,来减轻中间层的压力,更利于构造一个V,M的分离的架构。

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

    原文作者:YoKey
    原文地址: https://www.jianshu.com/p/c9384eef179e
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞