应用中同一Model多场景复用的最佳实践？以Customer模型为例

面对多模块仅需Customer部分属性的场景，不要走单一大模型或完全独立多模型的极端，推荐采用「核心实体+场景专用DTO」的分层方案，平衡维护性、数据安全性和性能。

具体实现方案 #

1. 定义核心Customer实体 #

先维护一个与数据源（如数据库）映射的核心实体，包含全量属性，作为所有场景的数据源基础：

// 数据库映射的核心实体，包含所有Customer属性
public class CustomerEntity {
    private Long id;
    private String fullName;
    private String email;
    private String phoneNumber;
    private String shippingAddress;
    private LocalDate registrationDate;
    private boolean isActive;
    // 其他全量属性...
    // 标准getter/setter
}

2. 为每个场景创建专用DTO #

每个模块根据自身需求定义仅包含所需属性的DTO（数据传输对象），明确模块间的数据边界：

场景1：仅需ID和姓名的模块

// 基础信息DTO，仅保留业务所需字段
public class CustomerBasicDTO {
    private Long id;
    private String fullName;
    
    // getter/setter
}

场景2：需10个属性的详情模块

// 详情页DTO，包含详细信息字段
public class CustomerDetailDTO {
    private Long id;
    private String fullName;
    private String email;
    private String phoneNumber;
    private String shippingAddress;
    private LocalDate registrationDate;
    private boolean isActive;
    // 其他所需属性...
    
    // getter/setter
}

场景3：仅需联系信息的模块

// 联系信息DTO，仅保留联系方式字段
public class CustomerContactDTO {
    private Long id;
    private String email;
    private String phoneNumber;
    
    // getter/setter
}

3. 用映射工具简化实体-DTO转换 #

避免手动编写大量重复的属性赋值代码，使用MapStruct或ModelMapper这类工具自动生成映射逻辑：

// MapStruct映射接口
@Mapper(componentModel = "spring")
public interface CustomerMapper {
    CustomerMapper INSTANCE = Mappers.getMapper(CustomerMapper.class);
    
    CustomerBasicDTO toBasicDTO(CustomerEntity entity);
    CustomerDetailDTO toDetailDTO(CustomerEntity entity);
    CustomerContactDTO toContactDTO(CustomerEntity entity);
}

业务代码中使用示例：

// 从数据库获取核心实体
CustomerEntity customer = customerRepo.findById(customerId).orElseThrow();
// 转换为对应场景的DTO
CustomerBasicDTO basicInfo = CustomerMapper.INSTANCE.toBasicDTO(customer);

方案优势 #

• 低维护成本：核心实体仅需维护一次，新增属性时只需在核心实体和需要该属性的DTO中添加，无需修改所有模块的模型。
• 数据安全：每个模块仅获取自身所需字段，避免敏感/冗余数据暴露。
• 性能优化：查询数据库时可通过投影查询（如JPQL的SELECT new ...）仅获取DTO需要的字段，减少数据传输量。
• 职责清晰：DTO与模块强绑定，修改某模块需求不会影响其他模块。

备选方案：接口分层（适合属性重叠度高的场景） #

如果不想引入DTO，可以通过接口拆分属性，核心实体实现多个接口：

// 基础信息接口
public interface HasBasicInfo {
    Long getId();
    String getFullName();
}

// 联系信息接口
public interface HasContactInfo {
    String getEmail();
    String getPhoneNumber();
}

// 核心实体实现所有接口
public class CustomerEntity implements HasBasicInfo, HasContactInfo {
    // 全量属性及接口方法实现
}

模块中依赖对应接口：

public void handleBasicInfo(HasBasicInfo customer) {
    System.out.println("ID: " + customer.getId() + ", Name: " + customer.getFullName());
}

这种方式仅在编译层面限制属性访问，实体仍包含全量字段，适合对数据传输量要求不高的场景。

总结 #

优先选择「核心实体+场景DTO」的方案，这是工业界处理此类问题的主流实践，能有效平衡各方面需求。映射工具的引入能大幅降低转换代码的冗余，提升代码整洁度。

内容的提问来源于stack exchange，提问作者Alex