Question

Order has_many AItems和BItems。正如您所知，这些项目基本相同，但有一个重要的商业原因可以单独对它们进行分类。想知道什么是干涸的最佳策略。我意识到这有点自以为是......但希望得到一些明确的观点和论点。

查看代码

目前我正在使用偏爱。像这样：

class AItemsController
  def new
  end
end

class BItemsController
  def new
  end
end

# view files layout
> views
  > AItems
    > new.html.erb
  > BItems
    > new.html.erb

# routing
get '/AItems/new'
get '/BItems/new'

# code for /views/AItems/new.html.erb
<%= render "layouts/items_new", object: "AItems" %>

# code for /views/BItems/new.html.erb
<%= render "layouts/items_new", object: "BItems" %>

我想知道是否更容易完全摆脱部分，只是做这样的参数：

class AItemsController
  def new
  end
end

class BItemsController
  def new
  end
end

# view files layout
> views
  > Items
    > new.html.erb

# routing
get '/items/new/:type'

# code for /views/Items/new.html.erb
# code from partial evaluating the param[:type] instead of a passed object

控制器代码

目前所有内容都是重复的...（我还没有尝试过DRYing）因为它看起来像这样（非常具有说明性，重点是只显示命名约定的字面上一切都基本相同）：

class AItemsController
  def new
    @items = AItems.joins(:order).where("orders.status_id IS NULL")
  end

  def do_something
    a_items_params.each do |item_params|
      key_var = item_params[:some_attribute]
      ...
    end
  end
end

class BItemsController
  def new
    @items = BItems.joins(:order).where("orders.status_id IS NULL")
  end

  def do_something
    b_items_params.each do |item_params|
      key_var = item_params[:some_attribute]
      ...
    end
  end
end

我还没有干这个，因为我对如何有点冲突。下面的例子是说明性的，如果代码不准确，请原谅，但希望你能得到主旨。

解决方案A：在某种程度上，我可以在每个控制器中保留操作定义，然后让操作中的代码来自共享关注点：

class AItemsController
  include SharedCode

  def new
    shared_new
  end

  def do_something
    shared_do_something
  end
end

解决方案B：将行动定义抽象为共同关注点：

class AItemsController
  included SharedAction

  shared_action("AItems")
end

解决方案C：将所有内容路由到一个单一控制器并再次使用params来区分（从视图中传递）

class ItemsController
  def new
    item_type = params[:item_type]
  end

  def do_something
    item_type = params[:item_type]
  end
end

型号代码

这个更加干净，我不需要大量的反馈，我只会使用关键方法/回调的共同关注点。

显然，一个人的答案会影响另一个人。例如，如果一切都通过单个控制器路由，那么我将使用参数而不是部分方法的单个视图。但由于控制器有多种DRYing选项，因此仍有争议的余地。

如果你已经读过这篇文章了，我会很高兴地评论这个问题是如何过于松散地定义的，以换取至少一些关于你会做什么的想法。如果你接管我的代码，对你来说什么更容易理解？

我正在努力学习，最好的办法就是征求多种观点以及利弊来衡量。

Answer 1

查看 InheritedResources Gem ：https://github.com/josevalim/inherited_resources

Inherited Resources通过制作控制器来加速开发继承所有宁静的行动，所以你只需要专注于什么重要。它使您的控制器更强大，更清洁同一时间。

或响应者宝石，替代继承资源：https://github.com/plataformatec/responders

一组响应程序模块，用于清理Rails 4.2+应用程序。

如何干掉基本上完全相同的2个控制器/模型/视图

1 个答案: