[译]|[译] 一个 Rails 开发者眼中的 Hanami
翻译自: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】听起来很吸引人,对吧?对我来说,确实如此,特别是因为我们钟爱的 Rails 常常被批评变得过于复杂,以及破坏了一些最佳实践(例如混合了域和数据层)。
内存使用率也可能是 Hanami 的一个潜在好处。Hanami 可能消耗更少的内存,并且速度更快(甚至五倍)(https://rpanachi.com/2016/03/...)。
我喜欢什么
初始化
初始化 Hanami 应用非常简单。 开始 页面解释了该如何做:
- 设置项目
- 创建第一个路由,并链接与之匹配的控制器行为,视图和模板
- 准备基本的测试
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::Validation
mixin(基于一个超棒的 Gem,dry-validation
)。Hanami 中的控制器响应事件开箱即用,然而你也可以根据你的需要,创建你自己的验证器对象。如果你想了解更多为什么验证器是一种反模式,我建议你看看 Piotr Solnica 的这个 视频。
Sequel
,另一个顶级 gem,来完成数据库的通信,你可以感谢这个给力的玩意儿的作者,Jeremy Evans。我喜欢 Hanami 存储思路的一个原因是,当我定义一个访问器,Hanami 的存储不会为我创建额外的公共结构。Hanami 只在这些方法被访问的时候,才会创建他们。
下面是一些我还没有用到的,我认为属于 Hanami 的额外优点:
- 你可以 一次操作许多条记录 ,而无需编写 SQL 查询。
- 它支持数据库约束。
其他
- Hanami 基于 Rack,这允许她可以使用许多 Rack 中间件(错误追踪,访问频率限制等等)
- Hanami 内置的终端,与 Rails 终端所提供的功能相类似,用起来很顺手
- Hanami 是一个现代 Web 框架,它提供大量的现代 Web 开发特性(资源管理,DB migration 系统,邮件系统,安全优先设计,等等。)
教程过于简单 教程只覆盖到了一些非常基本的用法。大量的选择分散在论坛、gitter 聊天室以及 stack overflow 之中。文档可以改进一些。可以提供一个简单的 CRUD 案例。而现在,通常我不得不阅读一些各种帖子,来了解如何实现某个功能。
此外,一些伟大的 gem 被合并到 Hanami 中的事实有时是一个诅咒,因为您必须了解哪些 API 基于什么 gem,然后深入研究 gem 的代码/文档以了解如何实现您想要的东西。
使用存储库有时候是糟糕的一件事 也许我还没有在 Hanami 存储库和 Sequel 上花足够的时间,但是我并没有真正看到一种简单的方法来 DRYing 查询的各个部分,所以我最终编写了具有许多共同部分的查询方法。
我还记得我在编写一个基于 GROUP BY 子句,返回额外列存储方法时遇到了困难。我花了很长时间才解决它。如果文档包含像这样更复杂的使用案例,那就太棒了!
总结 我得承认,我很喜欢使用 Hanami。不过,我不建议你使用它构建任何大型项目,或者把现有项目转换过去,除非你做好了花费大量时间在论坛、聊天室解决许多在 Rails 生态已经解决过的问题。
不过,我建议你使用它来实现一些你的新点子,我会继续使用它来构建我的非主要项目。谢谢你阅读。
推荐阅读
- 一个人的旅行,三亚
- 一个小故事,我的思考。
- 一个人的碎碎念
- 七年之痒之后
- 我从来不做坏事
- 异地恋中,逐渐适应一个人到底意味着什么()
- 【译】20个更有效地使用谷歌搜索的技巧
- 迷失的世界(二十七)
- live|live to inspire 一个普通上班族的流水账0723
- 遗憾是生活的常态,但孝顺这件事,我希望每一个人都不留遗憾