Hanami框架中Entity与Repository的区别是什么？

核心职责划分 #

Hanami 采用了和 Ruby on Rails 不同的架构设计，将原本 Rails 单 Model 承担的职责拆分为两类独立的对象，遵循单一职责原则：

• Hanami::Entity 实体类（对应 entities/user.rb）
  是纯领域数据对象，与持久层完全解耦，仅负责承载业务数据、封装和业务对象本身强绑定的无状态逻辑：比如衍生属性计算、不依赖数据库的自包含规则校验，你不需要连接数据库就可以直接初始化、调用实体类的所有方法。
• Hanami::Repository 仓库类（对应 repositories/user_repository.rb）
  是唯一和数据库交互的持久化层，所有增删改查、关联处理、事务操作、SQL 封装都要放在这个类中，相当于把 Rails Model 中所有和数据库交互的逻辑单独抽离封装。

关联关系、验证逻辑的存放规则 #

关联关系定义 #

关联逻辑全部放在 Repository 类 中声明即可，仓库会自动处理关联查询、预加载、级联操作的逻辑，实体类不需要感知关联的存在，仅在需要时读取对应属性即可。示例如下：

class UserRepository < Hanami::Repository
  associations do
    has_many :posts
    has_one :user_profile
    belongs_to :department
  end

  # 关联查询逻辑也封装在此
  def with_posts(user_id)
    users.combine(:posts).where(id: user_id).one
  end
end

验证逻辑 #

按验证规则的依赖场景分两类存放：

• 不依赖持久化状态的通用业务规则验证：比如用户名长度要求、邮箱格式校验，放在 Entity 类 中定义，示例如下：

  class User < Hanami::Entity
    validates :username, length: { minimum: 3, maximum: 20 }
    validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }
  end
  

• 依赖数据库状态的验证：比如用户名唯一性校验、外键存在性校验，需要查询数据库才能完成，放在 Repository 类 的持久化操作逻辑中，或者上层业务操作层实现即可。

与 Rails Active Record 模式的区别 #

Rails 的 Active Record 模式将数据承载、业务逻辑、持久化操作全部耦合在单个 Model 类中，优点是开发效率高、上手门槛低，缺点是复杂业务场景下很容易出现胖 Model 问题，维护成本快速上升。Hanami 的拆分设计更适合中大型项目的长期迭代，边界更清晰，也更方便做单元测试（实体类的单元测试不需要依赖数据库即可运行）。

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