Будучи как DRY, насколько это возможно в Ruby на Rails приложение

В чем проблема DRY с определением параметров attachment_fu дважды?

Если файлы не имеют того же типа и хранятся в одном и том же месте, вы не будете повторять ничего в конфигурации.

Конечно, у вас будет два объявления has_attachment, но варианты будут в основном отличаться (одно объявление для ваших аватаров, а другое для ваших pdf и т. д.

99.99% кода для обработки вложений будет похоронен в библиотеках attachment_fu, ваш код конфигурации должен быть довольно DRY по умолчанию =)

Является ли поддержка Аватара "outsourcing" полностью для Граватара вариантом? Есть некоторые плагины Rails, которые будут отображать аватары, размещенные Gravatar. Возможно, Вам не придется заново изобретать колесо там.

То, что описывает wfarr, будет наследованием одной таблицы, что я сейчас делаю в этой ситуации. У меня есть одна таблица для активов, которая содержит все необходимые столбцы attachment_fu, плюс дополнительный столбец с именем type, который будет содержать фактическое имя модели. У меня есть модель для активов и дополнительные модели для конкретных типов загрузки, которые наследуются от активов:

asset.rb:

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

avatar.rb:

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

pdf.rb:

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

Я бы склонялся к использованию родительского класса с подклассами для различных способов, которыми вы собираетесь фактически использовать вложения в своем приложении. Это может быть не решение DRYest, однако оно довольно хорошо поддается логическому шаблону.

Не могли бы вы использовать полиморфные Ассоциации ?

Я собираюсь поразить это в своем приложении с помощью attachment_fu, поэтому я не совсем уверен в attachment_fu, но для плагина old school File Column я бы использовал полиморфные Ассоциации.

Моя модель "file" будет:

    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 больше не подходит, поскольку он борется с Safari 3.x и больше не поддерживается. Это было приятно и просто, хотя... Ах, старые добрые времена...

Для чего это стоит, Я думаю, что Патрик Беркли проделал хорошую работу с обработкой нескольких вложений через плагин Paperclip. Он изложил свою работу здесь:

http://gist.github.com/33011