在 Ruby on Rails 应用程序中尽可能 DRY答案

【问题标题】：Being as DRY as possible in a Ruby on Rails App在 Ruby on Rails 应用程序中尽可能 DRY
【发布时间】：2010-09-06 09:45:47
【问题描述】：

我目前正在为 Rails 应用程序使用超棒的 attachment-fu 插件，但作为一名新手开发人员，我从未遇到过像我遇到的那样的场景。

基本上，我在两个层面上使用了 attachment-fu 插件。

我的问题是在这些情况下保持干、清晰和一致的最佳使用实践是什么。

很明显，在这两个类中定义和执行插件是没有意义的，但我觉得很奇怪（可能没有根据），只是继续在虔诚的 Application 类中设置它。

两者之间有什么关系，还是父类是要走的路？

谢谢！

【问题讨论】：

【解决方案1】：

“外包”头像支持完全支持Gravatar 是一种选择吗？有一些 Rails 插件可以显示 Gravatar 托管的头像。您可能不需要在那里重新发明轮子。

【讨论】：

【解决方案2】：

我倾向于使用父类，并根据您打算在应用程序中实际使用附件的不同方式进行子类化。它可能不是可用的 DRYest 解决方案，但它非常适合逻辑模式。

【讨论】：

【解决方案3】：

两次定义 attachment_fu 设置的 DRY 问题是什么？

除非文件属于同一类型并存储在同一位置，否则您不会在配置中重复任何内容。

当然，您将有两个 has_attachment 声明，但选项大多不同（一个声明用于您的头像，另一个用于您的 pdf 等。

99.99% 的附件处理代码将隐藏在 attachment_fu 库中，默认情况下您的配置代码应该相当 DRY =)

【讨论】：

【解决方案4】：

你不能用Polymorphic Associations吗？

我即将在我的应用程序中使用 attachment_fu，所以我不太确定 attachment_fu，但对于老式的 File Column 插件，我会使用多态关联。

我的“文件”模型是：

    class FileUpload < ActiveRecord::Base
      belongs_to :fileable, :polymorphic => true
      file_column :name
    end

然后任何需要文件附件的模型都是这样的：

    class Company < ActiveRecord::Base
      has_many :file_uploads, :as => :fileable
    end

文件列不再好用了，因为它在 Safari 3.x 上出现问题并且不再维护。不过它很好很简单……啊，过去的美好时光……

【讨论】：

【解决方案5】：

wfarr 描述的是single table inheritance，这是我目前在这种情况下所做的。我有一个 Assets 表，其中包含所有必要的 attachment_fu 列，以及一个名为 type 的额外列，它将保存实际的模型名称。我有一个资产模型和从资产继承的特定上传类型的其他模型：

资产.rb：

class Asset < ActiveRecord::Base
  ... attachment_fu logic ...
end

头像.rb:

class Avatar < Asset
  ... avatar specific attachment_fu logic ...
end

pdf.rb:

class PDF < Asset
  ... PDF specific attachment_fu logic ...
end

【讨论】：

【解决方案6】：

就其价值而言，我认为 Patrick Berkeley 在通过 Paperclip 插件处理多个附件方面做得很好。他在这里概述了他的工作：

【讨论】：