想找一套能让你在写大型Ruby项目时不再被代码纠缠成一团的框架？Hanami（hanamirb.org）就是个值得蹲守的答案。它不是那种上来就给你一堆魔法的全栈巨无霸，而是把“组织代码”这件事做到极致——每个HTTP端点、每个业务操作、每段数据访问都各归其位，页面里也明确写着它主打“明确分离关注点和显式业务逻辑”。如果你受够了项目大了之后改一处崩三处，那Hanami这套模块化思路，大概率能让你重新找回写代码的清爽感。

【主要能力】
– Relations数据层定义：通过独立Relations类集中描述数据表的访问模式，把查询逻辑从控制器和模型里抽离出来，保持持久化层干净。
– Repos组合查询：利用Repository对象组合多个Relation操作，执行复杂数据检索，返回业务可直接使用的实体结构。
– Structs实体映射：用轻量不可变Structs作为数据载体，避免ActiveRecord式贫血模型带来的臃肿感，让数据流转更透明。
– Operations业务封装：每个Operation专职处理一条业务规则，显式声明success和failure分支，方便单测和组装成业务链。
– Actions独立动作类：每个URL端点对应一个Action类，专注解析请求参数和返回响应，不掺和业务细节，想测哪层测哪层。
– Views独立视图对象：视图类专门负责加载数据、装饰变量和渲染模板，Controller不用再管HTML输出，模板改动影响面小。
– Slices模块化切片：用Slices把应用切成独立子域，比如“用户中心”“订单系统”各占一块，边界清晰，依赖隔离，适合大团队并行开发。

【访问地址】
Hanami官方入口
https://hanamirb.org

【适用人群】
如果你是个Ruby老手，正负责一个要长期演进的中大型系统，团队里大家对架构有共识、愿意花时间设计边界，那Hanami的模块化切片和显式分层会让你如鱼得水。但要是你只想快速撸个小博客或者MVP验证想法，那它比Rails多出来的那些结构约束可能会让你觉得步子太重。另外，如果团队里全是Rails新手，上来就玩Slices和Operations，学习曲线可能会有点陡，建议至少有一两个人先吃透文档再铺开。

【写在最后】
Hanami给我的感觉更像一套“软件架构方法论”而不是单纯的框架——它不逼你接受隐式魔法，而是鼓励你把每个组件都当作头等公民来设计和测试。从Relations到Operations再到Slices，每个概念都对应一个清晰的设计决策，这在中大型项目里能省下不少回头债。当然，它的生态插件确实没Rails那么热闹，很多通用功能（比如后台管理、文件上传方案）可能需要自己拼装。但如果你恰好是个重视代码整洁度、享受搭建结构化系统的工程师，那花一个周末试试Hanami，说不定会打开新世界的大门。这类框架永远是小众里的精品，适合有主见、不随大流的团队。

| 对比维度 | Hanami (hanamirb.org) | Ruby on Rails |
|———|———————-|—————|
| 架构风格 | 模块化显式分层，Slice隔离子域 | 约定优于配置，MVC一体，隐式依赖 |
| 数据层 | Relations+Repos+Structs三层分离 | ActiveRecord直接绑Model，简单直接 |
| 业务逻辑 | Operation独立对象，显式成功失败分支 | Service Object需自建，常见放Model或Controller |
| 路由与Action | 每端点独立Action类，职责单一 | Controller内多个Action方法，组织灵活 |
| 扩展生态 | 第三方专用Gem数量较少，需自行集成 | Gem库庞大，开发速成型方案随处可得 |
| 学习成本 | 概念偏多，需理解架构设计意图 | 上手快，官方文档全，教程遍地 |
| 维护表现 | 结构清晰，适合长期演进与团队协作 | 中小型快速迭代舒服，大型易臃肿 |

内容由变脸导航网友情收录，若发现链接打不开或信息有误，请通过网站反馈渠道告知我们。