ruby-on-rails - 在 Ruby on Rails 应用程序中尽可能 DRY

Question

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

本质上，我在两个级别上使用了 attachment-fu 插件。

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

显然，在这两个类中定义和执行插件是没有意义的，但是对我来说有一些非常奇怪的东西（可能没有根据），只是继续在虔诚的 Application 类中设置它。

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

谢谢！

score 3 · Accepted Answer

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

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

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

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

score 2 · Accepted Answer

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

score 2 · Accepted Answer

wfarr 描述的是单表继承，这是我目前在这种情况下所做的。我有一个 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

score 1 · Accepted Answer

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

score 0 · Accepted Answer

你不能使用多态关联吗？

我即将在我的应用程序中使用 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

File Column 不再好用，因为它在 Safari 3.x 上很糟糕并且不再维护。不过这很好很简单……啊，过去的美好时光……

score 0 · Accepted Answer

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

6 回答 6