Gem 大家怎么看待 trailblazer 这个 gem?

saiga · 2014年11月29日 · 最后由 fleuria 回复于 2015年01月05日 · 6116 次阅读
本帖已被管理员设置为精华贴

https://github.com/apotonick/trailblazer

Trailblazer is a thin layer on top of Rails. It gently enforces encapsulation, an intuitive code structure and gives you an object-oriented architecture.

目前我看到的功能:

  1. 将 model 改成贫血模型
  2. 将持久化操作从 controller 抽取出来,放到内部类中
  3. 解决全局 helper 问题,action 和 helper 都放到 cell 里面了(类似 volt 的 controller)
  4. 校验放到 form object 里面(与 reform 和 cell 同一个作者)

我的理解就是集成了 reform 和 cell,然后自己实现了一套 service 层。

btw, 关于 service 层和 rails model 过分充血好像之前也有争论,不知道大伙对这个 gem 有什么看法?

对于重的 rails 应用应该是有意义的,就是 service 层 +Form 层,自己实现类似的分离也可以.

昨天把这个 gem 用在自己的新项目中,感觉完成度略低,测试基本没有,只能说勉强能用。不过看的出来作者野心挺大的,队列,上传都有考虑。 controller 的确干净很多,model 的话除了将 validates 移出来外好像没多少改进(trailblazer 采用的更新方式导致 dirty check 无效了),目前配合 conern 还 ok

一个月前找 Rails app 相关架构的时候找到了 Trailblazer,但扫了一下项目我就没细看了。

这个框架的根本思路是用传统的 OOP 方式去组织代码的。但 Rails 从设计上就是比较反 OOP 的。就像有人在 Twitter 上开玩笑的,有复杂的业务逻辑怎么办?

  1. 加 validation
  2. 不够?加 concern
  3. 还不够?加 callback

最后就见鬼了……

所以我不大看好任何在 Rails 基础上加 gem/library 之类去大规模改变 Rails 做法的事情,但正好 Trailblazer 就这么干的。对 Rails 而言,不是不能用 OOP 解决问题,比如 service object,但要适量,一味 OOP 就失去 Rails 最大的便利性了。失去便利性导致的效率倒退对我而言比软件架构不好更难以接受。

要找基于 OOP 的思路的框架,一切重新来过的 Lotus 也许是个更好的选择。

#3 楼 @darkbaby123 rails 不是反 oop,相反由于 ruby 的关系到处都是 oop,只是不提倡 java 那套。

http://web-colle.herokuapp.com/ 这个是我上个星期开始写的网站,前天上线了,其中就有用到这个 gem。整体感觉就是不怎么适合小网站:

  1. service 层的代码不能复用。独立业务逻辑不多的话,代码跟没用之前一样,都丢到 model 层了
  2. service 层由于是使用嵌套的内部类,而且很多时候不能复用,导致代码行数增长的很快...
  3. Trailblazer 的 service 代码是写到 model 里的内部类,search_controller 这些 modeless controller 的代码就不知道放哪里了...
  4. 替代 callback 就意味着得时刻注意手动开启事务
  5. BUG 真的太多太多了...

嗯,说反 OOP 是不大恰当。只是 Rails 有自己的一套理念,不提倡过度设计。其实对简单的项目而言,因为 model 不会太 fat,Rails 的那一套(比如 concern)是既简单又便利的。

Trailblazer 的 service 层有时候还把东西搞复杂了,而且像 model 里面再实现内部类的做法感觉有点强迫症了,比如这个例子:

class Comment < ActiveRecord::Base
  class Create < Trailblazer::Operation
    def process(params)
      # do whatever you feel like.
      self
    end
  end
end

这样不知道怎么分文件存放 operation,但如果都写成一个文件显然 model 太大了。

不过貌似 Trailblazer 也不强制开发者一定要照它的来,就是说简单情况用 Rails 就够了,不知道是不是这样?

#5 楼 @darkbaby123

嘛,用内部类也是无可奈何的事,毕竟这个类不仅要处理逻辑,还要负责生成和校验表单。 这里是我项目里的一段代码:

class WebPage < ActiveRecord::Base
  class Create < Trailblazer::Operation
    include CRUD

    model WebPage, :create

    contract do
      model WebPage

      property :url, validates: { presence: true }
      property :title, validates: { presence: true }
      property :description, validates: {length: {maximum: 200, allow_blank: true}}
      property :tag_list
    end

    def process(params)
      validate params[:web_page] do |op|
        op.save
      end
    end
  end
end
# web_pages_controller.rb
class WebPagesController < ApplicationController

  def new
    form WebPage::Create
  end

  def create
    run WebPage::Create do |op|
      redirect_to web_pages_url and return
    end
    render :new
  end
end

去掉了 model 里面的 validation,去掉了 strong params,controler 里面没有任何持久化相关的代码 虽然有点强迫症,但看起来还可以 😄

不过也确实如你所说,service 文件增长超快,我那点代码都写了 7,8 个内部类。而且由于设计表单校验,还要再写一套区分前后台,感觉作者在这方面的考虑确有所欠缺。

不知不觉就加精了 XD

9 楼 已删除

没用. 代码不多可以玩玩, 代码多了就头痛了

感觉这东西就是过度设计

  • 加 validation
  • 不够?加 concern
  • 还不够?加 callback
  • 最后就见鬼了……

这种比较喜欢抽一个 Form Object 出来,把 validation 和事务塞里面,尽量不用 callback

需要 登录 后方可回复, 如果你还没有账号请 注册新账号