共计 2657 个字符，预计需要花费 7 分钟才能阅读完成。
翻译自：Hanami: Thoughts of a Rails developer – DEV Community
引子
我还记得第一次据说 Hanami 框架的时候，是几年前，在 Wroclove.rb 会议的时候。过后并没有真正引起我的关注，那时我刚刚进入 Ruby 世界，正 100% 专一于学习 Rails，我不想在大脑认知上，接管另一个框架的信息。
当初，我曾经应用 Rails 工作了好几年，我有点感到疲乏了，我认为当初是接触全新概念的机会。我想起 wroclove.rb 的谈话，我决定学习 Hanami。我最喜爱的学习形式是边做边学，所以我开始了一个名为 flashcard-genius 的玩具我的项目。这个利用的目标是帮忙我学习意大利语单词，它容许用户创立、共享和记忆多组卡片。
接下来大略两个月的业余时间，我开发了这个原型产品（曾经上线：http://flashcard-genius.com）。它应用了根本的的服务端渲染以及 CRUD 操作，它迫使我学习了各种各样的 Hanami 概念，并克服了多个应用过程中所遇到的阻碍。
在本文，我将与你分享我对于 Hanami 的一些印象。
为什么要应用 Hanami？
Hanami 的作者 Luga Guidi，心愿能够去 Rails 化。他的次要愿景是构建一个平安的，功能丰富的 Web 框架，这个框架的构造遵循简洁的架构准则，并依赖于通过实战测试的第三方库，如 Sequel，Rack，以及 dry-rb 这些。
听起来很吸引人，对吧？对我来说，的确如此，特地是因为咱们钟爱的 Rails 经常被批评变得过于简单，以及毁坏了一些最佳实际（例如混合了域和数据层）。
内存使用率也可能是 Hanami 的一个潜在益处。Hanami 可能耗费更少的内存，并且速度更快（甚至五倍）(https://rpanachi.com/2016/03/…)。
我喜爱什么
初始化
初始化 Hanami 利用非常简单。开始 页面解释了该如何做：
- 设置我的项目
- 创立第一个路由，并链接与之匹配的控制器行为，视图和模板
- 筹备根本的测试
良好的第一印象对我十分重要，因为能够直观的看到事物的变动，使我有趣味持续理解更简单的概念，来构建我的 app。
Hanami 我的项目是一个“渺小的”
https://guides.hanamirb.org/a…
Hanami 能够容许存在多个 App 在一个我的项目中，这有助于我的项目大了之后的解构和拆分。同样的，每个我的项目有本人独立的“lib”文件夹。
实体、存储库、验证对象和交互响应器代替了胖数据模型
Hanami 尽力阻止开发者在应用 Hanami 中，犯在应用 Rails 中常犯的谬误。
- 相较于在模型中，间接应用数据库查询方法，Hanami 提供了存储类。刚开始应用的时候，仿佛有点多此一举，但当前你会感触到她的益处。
- 不应用不不便进行测试的生命周期回调（after_create，after_build 等等），Hanami 激励您应用被称为交互器的服务对象。
- Hanami 中的 模型，默认只提供相应表的只读拜访。相较于 active record 模型，默认就创立大量的模型办法（如 username，username_changed，username_did_change? 等），这是个非常轻量级的实现。
- Hanami 的创造者们，得出结论，验证器不应该成为模型的一部分，因为数据的验证高度依赖用例。因而，他们没有在模型上提供验证机制，而是创立了
Hanami::Validationmixin（基于一个超棒的 Gem，dry-validation）。Hanami 中的控制器响应事件开箱即用，然而你也能够依据你的须要，创立你本人的验证器对象。如果你想理解更多为什么验证器是一种反模式，我倡议你看看 Piotr Solnica 的这个 视频。
数据拜访和管制
我后面提到过，在 Hanami 中，数据的查问和管制，通过相应的存储类。Hanmi 开发者决定引入 Sequel，另一个顶级 gem，来实现数据库的通信，你能够感激这个给力的玩意儿的作者，Jeremy Evans。
我喜爱 Hanami 存储思路的一个起因是，当我定义一个拜访器，Hanami 的存储不会为我创立额定的公共构造。Hanami 只在这些办法被拜访的时候，才会创立他们。
上面是一些我还没有用到的，我认为属于 Hanami 的额定长处：
- 你能够 一次操作许多条记录，而无需编写 SQL 查问。
- 它反对数据库束缚。
没有全局视图帮忙办法
模板是以绝对应的视图类作为后端的，在 Rails 中，这些视图帮忙办法将被实现为全局的帮忙办法。这使得 ERB 模板所用到的一些视图办法难以被测试。
其余
- Hanami 基于 Rack，这容许她能够应用许多 Rack 中间件（谬误追踪，拜访频率限度等等）
- Hanami 内置的终端，与 Rails 终端所提供的性能相相似，用起来很棘手
- Hanami 是一个古代 Web 框架，它提供大量的古代 Web 开发个性（资源管理，DB migration 零碎，邮件系统，平安优先设计，等等。）
有什么不称心的中央？
生态环境小
不言而喻，Hanami 是一个比 Rails 规模小的多的我的项目，所以相干的 gem，手册等都不是很多。同样的，Rails 有很多第三方服务的 SDKs，在 Rails 中，你能够间接应用。而在 Hanami 中，在这些中央你往往须要花一些额定的工夫整合。
教程过于简略
教程只笼罩到了一些十分根本的用法。大量的抉择扩散在论坛、gitter 聊天室以及 stack overflow 之中。文档能够改良一些。能够提供一个简略的 CRUD 案例。而当初，通常我不得不浏览一些各种帖子，来理解如何实现某个性能。
此外，一些平凡的 gem 被合并到 Hanami 中的事实有时是一个咒骂，因为您必须理解哪些 API 基于什么 gem，而后深入研究 gem 的代码 / 文档以理解如何实现您想要的货色。
应用存储库有时候是蹩脚的一件事
兴许我还没有在 Hanami 存储库和 Sequel 上花足够的工夫，然而我并没有真正看到一种简略的办法来 DRYing 查问的各个局部，所以我最终编写了具备许多独特局部的查询方法。
我还记得我在编写一个基于 GROUP BY 子句，返回额定列存储办法时遇到了艰难。我花了很长时间才解决它。如果文档蕴含像这样更简单的应用案例，那就太棒了！
总结
我得抵赖，我很喜爱应用 Hanami。不过，我不倡议你应用它构建任何大型项目，或者把现有我的项目转换过来，除非你做好了破费大量工夫在论坛、聊天室解决许多在 Rails 生态曾经解决过的问题。
不过，我倡议你应用它来实现一些你的新点子，我会持续应用它来构建我的非次要我的项目。谢谢你浏览。
