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层来说：
- 我不想知道你的
version是干嘛的
- 我只需要一个List<User>，User里有
id，name以及男or女即可
- 我不想要什么
uid，user_name，gender等这样后台强加给我的命名或数据类型（即便我们有GSON的@SerializedName注解）
- 更重要的是我不想拿到一个为
null的userList，
VO层public final class User{
public String id;
public String name;
public boolean isMale;
}
Mapperpublic 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层
如何解决痛点的？-
痛点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;
}
}
总结：PS：文中转换的方式是构建Mapper接口，使用起来很方便。
你也可以像Android-CleanArchitecture一样创建独立的Mapper类：在Mapper类进行transform，优点是可以保持DTO与VO的干净和独立；
|
