在 Ruby on Rails 应用程序中尽可能保持 DRY

题

我目前正在为 Rails 应用程序使用很棒的 Attachment-fu 插件，但作为一名新手开发人员，我从未遇到过像我遇到的情况。

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

我的问题是，在这些情况下，最好的使用实践是什么？干燥, 、清晰、一致。

显然，在这两个类中定义和执行插件是没有意义的，但是对于我来说，在神圣的 Application 类中继续进行所有设置并进行设置，这对我来说是非常奇怪的（可能是没有根据的）。

中间有什么东西吗，还是父类是正确的选择？

谢谢！

解决方案

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

其他提示

定义两次 Attachment_fu 设置有什么 DRY 问题？

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

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

99.99% 处理附件的代码将被埋在 Attachment_fu 库中，默认情况下你的配置代码应该非常 DRY =)

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

wfarr 描述的是单表继承, ，这就是我目前在这种情况下所做的。我有一个资产表，其中包含所有必需的 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

你不能用多态关联?

我即将在我的应用程序中使用attachment_fu来实现这一点，所以我不太确定attachment_fu，但对于老派来说文件栏插件，我会使用多态关联。

我的“文件”模型是：

    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 上失效并且不再维护。虽然它很好而且很简单......啊，过去的美好时光……

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

许可以下： CC-BY-SA 和归因