0

我有一个很棒的工作时间表应用程序。现在一切运行良好，是时候重构了！尤其是有些观点真的很复杂。所以我想开始使用装饰器来清理它们。

另一件事是我使用了大量的服务对象。虽然它们很棒并且让我的模型保持干净，但在我的视图中使用它们并不是我想要的。我在这里寻找一些重构建议。让我们考虑以下视图代码片段：

  .row
    .span12#timesheet
      - days = @timesheet_builder.get_days_in_month

      %table.table.days
        %tbody
          - (1..days).each do |day_nr|
            - activity_date = Date.new(@timesheet.year, @timesheet.month, day_nr)

            - if @timesheet_builder.is_workday?(day_nr)
              - day_type = "workday"
            - else
              - day_type = "non_workday"

            %tr.day(class=day_type)
              %td.date{ "data-title" => "#{I18n.t('.timesheet.day_nr')}" }
                .day_abbr= @timesheet_builder.get_day_name(day_nr)
                .day_nr= day_nr

您看到的是一个很棒的 TimesheetBuilder 服务对象，可以获取一个月中的天数并检查一天是否是工作日。根据结果​​，表格中的一行获得不同的颜色或其他标记。

它工作得很好，但我怎样才能重构它以使视图更简单？我可以在装饰器中使用服务对象吗？

4

2 回答 2

2

使用 rails 约定并将它们粘贴在帮助程序中：

  module TimeSheetHelper  #automatically included within TimeSheet views
    def work_day_class(day)
      @timesheet_builder.is_workday?(day_nr) ? "workday" : "non_workday"
    end
  end

同时..回到你的观点：

  ...
  %tr.day(class=work_day_class(day_nr))
  ...

于 2013-10-10T12:40:37.363 回答
2

作为一名经验丰富的 Rails 开发人员，我倾向于不喜欢 Rails 助手。当助手数量增加时，它往往会变得一团糟。但是您的想法是正确的-使用中间对象来封装您的业务逻辑。您可以创建自己的解决方案，就像在 Railscast中一样， 或者您可以使用一些现成的库，如 draper，请参阅这些以获取更多信息： http ://railscasts.com/episodes/286-draper https://github。 com/drapergem/draper

我觉得使用您建议的方法是比在助手内部制造垃圾更好的 OOP/OOD 解决方案。另一个优点是，我发现测试封装在类中的逻辑比测试模块更容易和更清晰。

于 2013-10-10T12:49:42.160 回答