仓储层（Repository）应操作实体类还是仅返回数据模型？

这个问题没有绝对标准答案，核心取决于你的架构设计目标和实体类的职责定位，下面分两种常见场景说明：

场景1：实体类是带业务逻辑的领域模型 #

如果你的Person类是领域实体（本身包含业务行为，比如判断成年、处理名称修改规则），那仓储层直接返回Person实体类是更合理的选择：

• 仓储层的核心职责是封装数据持久化逻辑，把数据库数据映射为领域实体后，上层业务代码可以直接调用实体的业务方法，无需额外做数据转换
• 示例代码：

  // 带业务逻辑的领域实体
  class Person {
      private int id;
      private String name;
      private int age;
  
      public boolean isAdult() {
          return age >= 18;
      }
  
      // 构造方法、getter/setter等
  }
  
  // 仓储层直接返回领域实体
  public interface PersonRepository {
      Person findPersonById(int id);
  }
  

  这种模式下，仓储层相当于领域模型和数据库之间的桥梁，既避免了上层重复做转换，又保证了领域实体的业务逻辑能被直接复用。

场景2：实体类仅作为无逻辑的数据载体 #

如果你的Person类只是单纯的数据传输对象（DTO），或者完全和数据库表结构绑定，这时拆分出PersonModel作为仓储层返回对象，再在服务层转换为业务用的Person实体（或直接使用PersonModel）也是可行的：

• 优势是隔离数据库表结构变化对业务层的影响：比如数据库新增字段，只需要修改PersonModel，不需要改动业务用的Person类
• 示例代码：

  // 仓储层返回的数据库映射模型
  data class PersonModel(
      val id: Int,
      val name: String,
      val age: Int,
      val dbOnlyField: String // 数据库特有的字段，业务层不需要
  )
  
  // 业务层使用的实体（或DTO）
  class Person(
      val id: Int,
      val name: String,
      val age: Int
  ) {
      // 业务逻辑
  }
  
  // 仓储层接口
  interface PersonRepository {
      PersonModel findPersonById(int id);
  }
  
  // 服务层做转换
  class PersonService {
      private val repo: PersonRepository = ...
  
      fun getPerson(id: Int): Person {
          val model = repo.findPersonById(id)
          return Person(model.id, model.name, model.age)
      }
  }
  

  这种模式适合数据库结构频繁变动或者业务层与数据库层需要强隔离的场景，但会增加一层转换代码的工作量。

总结建议 #

• 若采用DDD（领域驱动设计）架构，优先让仓储层返回带业务逻辑的领域实体，符合DDD中仓储层为领域模型服务的原则
• 若为简单CRUD架构，或数据库与业务模型差异较大，用独立的数据模型作为仓储层返回对象，降低耦合度
• 避免过度设计：如果Person和PersonModel结构完全一致、无业务逻辑差异，强行拆分只会增加冗余代码，直接返回Person即可

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