传输对象模式：业务对象、传输对象、组装器，以及远程调用中的数据封装

说实话，传输对象模式（Transfer Object Pattern）是我在早期做分布式系统时，踩坑踩得最多的地方之一。那时候我刚接手一个老项目，每次远程调用都要传十几个参数，代码写得跟裹脚布似的。后来我才意识到，其实我们需要一个专门的角色来负责数据搬运——这就是传输对象。

什么是传输对象模式？

简单来说，传输对象就是用来在系统各层之间、或者跨网络传输数据的轻量级容器。它不包含任何业务逻辑，只负责装数据。你想想看，如果每次远程调用都要把业务对象直接暴露出去，那耦合度得多高？

这个模式有三个核心角色：

• 业务对象（Business Object）：真正干活的，包含业务逻辑和数据。
• 传输对象（Transfer Object）：纯数据容器，用来在网络上传输。
• 组装器（Assembler）：负责在业务对象和传输对象之间做转换。

我个人习惯把传输对象叫做“数据快递员”——它不关心数据怎么来的，也不关心数据怎么用，只管安全送到。

为什么需要传输对象？

我记得有一次，团队里有个同事直接把实体类（Entity）序列化后扔到消息队列里。结果呢？因为实体类里关联了太多懒加载的代理对象，序列化时直接报错。更麻烦的是，实体类的变更会直接影响所有消费者——这就是典型的耦合问题。

传输对象能解决几个核心痛点：

• 减少网络调用次数：一次调用传一个对象，而不是传多个参数。
• 解耦：业务对象的变化不会影响远程调用方。
• 安全性：只暴露必要的数据，避免泄露内部结构。

代码示例：Java 实现

先看一个简单的用户信息传输场景。假设我们有一个 User 业务对象，但远程调用时只需要部分字段。

// 业务对象（带业务逻辑）
public class User {
    private Long id;
    private String username;
    private String password;  // 敏感字段，不能传输
    private String email;
    private String phone;
    
    public boolean validatePassword(String input) {
        // 业务逻辑
        return this.password.equals(input);
    }
    // getters/setters...
}

// 传输对象（纯数据）
public class UserDTO implements Serializable {
    private Long id;
    private String username;
    private String email;
    private String phone;
    
    // 只包含需要传输的字段
    // getters/setters...
}

// 组装器
public class UserAssembler {
    public static UserDTO toDTO(User user) {
        if (user == null) return null;
        UserDTO dto = new UserDTO();
        dto.setId(user.getId());
        dto.setUsername(user.getUsername());
        dto.setEmail(user.getEmail());
        dto.setPhone(user.getPhone());
        return dto;
    }
    
    public static User toEntity(UserDTO dto) {
        // 反向转换，通常用于更新场景
        User user = new User();
        user.setId(dto.getId());
        user.setUsername(dto.getUsername());
        user.setEmail(dto.getEmail());
        user.setPhone(dto.getPhone());
        return user;
    }
}

C++ 实现示例

C++ 里做传输对象，要注意内存管理和序列化。我一般用 Protobuf 或者自己写简单的序列化。

// 业务对象
class User {
private:
    int64_t id_;
    std::string username_;
    std::string password_;
    std::string email_;
    std::string phone_;
    
public:
    bool ValidatePassword(const std::string& input) {
        return password_ == input;
    }
    // getters/setters...
};

// 传输对象
struct UserDTO {
    int64_t id;
    std::string username;
    std::string email;
    std::string phone;
    
    // 序列化到字节流
    std::vector<char> Serialize() const;
    static UserDTO Deserialize(const std::vector<char>& data);
};

// 组装器
class UserAssembler {
public:
    static UserDTO ToDTO(const User& user) {
        UserDTO dto;
        dto.id = user.GetId();
        dto.username = user.GetUsername();
        dto.email = user.GetEmail();
        dto.phone = user.GetPhone();
        return dto;
    }
};

传输对象在远程调用中的应用

远程调用（RPC、REST、消息队列）是传输对象的主战场。说白了，你不可能把整个业务对象序列化后扔到网络上——太重了，而且不安全。

我建议的做法是：

1. 按需设计：每个远程接口定义自己的传输对象，不要复用同一个 DTO 到处传。
2. 版本控制：传输对象一旦发布，字段增减要谨慎。我见过因为加了个字段导致老版本反序列化失败的惨案。
3. 扁平化：嵌套层次别太深，否则序列化性能会下降。

SVG 结构图：传输对象模式的核心流程

避坑指南

我曾经在一个金融项目中，把传输对象和业务对象混在一起用。结果呢？每次业务逻辑变更，都要同步修改序列化逻辑，而且一不小心就把敏感字段暴露了。后来花了整整两周重构，才把两者彻底分开。

这里有几个我踩过的坑，你一定要注意：

• 别把传输对象当业务对象用：传输对象里不要加业务方法，哪怕只是简单的校验。否则你会陷入“这个校验到底该在哪做”的混乱中。
• 注意序列化兼容性：Java 的 serialVersionUID、C++ 的版本号，这些细节决定了你的系统能不能平滑升级。
• 传输对象不要太大：一次传几百个字段？那还不如直接传业务对象。传输对象应该只包含当前接口需要的数据。

嗯，关于传输对象模式，我就讲这么多。记住，设计模式不是银弹，但用对了地方，能省你不少事。