Будучи как можно сухим в приложении Ruby on Rails

Question

В настоящее время я использую удивительный плагин для вложения-fu для приложения Rails, но, как начинающий разработчик, я никогда не сталкивался со сценарием, подобным тому, который я нашел я сам.

По сути, я использую плагин attachment-fu на двух уровнях.

1. Это для пользовательских аватаров в пользовательском классе.
2. Разрешить файловые вложения (PDF и т. Д.) В системе обмена сообщениями.

Мой вопрос заключается в том, что лучше всего использовать практика будет в таких ситуациях, чтобы оставаться DRY, ясно и последовательно.

Очевидно, что нет смысла определять и исполнять плагин в обоих классах, но есть что-то очень странное для меня (возможно, необоснованное) о том, что нужно идти вперед и устанавливать его в божественном классе приложений.

Есть ли что-то промежуточное, или родительский класс - путь?

Спасибо!

Answer 1

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

Answer 2

Поддерживается ли поддержка «аутсорсинга» до Gravatar? Есть некоторые плагины Rails, которые будут отображать аватары, размещенные Gravatar. Возможно, вам не нужно будет изобретать колесо.

Answer 3

Какая проблема с DRY с определением настроек attachment_fu дважды?

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

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

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

Answer 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 

Файл Column не уедешь, как это borks на сафари 3.x и больше не поддерживается. Это было красиво и просто, хотя ... Ах, старые добрые времена ...

Answer 5

Описание wfarr будет single table inheritance, что я и делаю в этой ситуации. У меня есть одна таблица для Assets, которая содержит все необходимые столбцы 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 

Answer 6

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

http://gist.github.com/33011