Быть максимально СУХИМ в приложении Ruby on Rails

Question

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

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

1. Предназначен для аватаров пользователей в классе пользователей.
2. Разрешить вложения файлов (PDF-файлы, и т. д.) в системе обмена сообщениями.

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

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

Есть ли что-то среднее или лучше использовать родительский класс?

Спасибо!

Answer 1

Я бы склонялся к использованию родительского класса с подклассами для различных способов использования вложений в вашем приложении.Возможно, это не самое СУХОЕ доступное решение, однако оно довольно хорошо поддается логическому шаблону.

Answer 2

В чем проблема DRY с двойным определением настроек Attachment_fu?

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

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

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

Answer 3

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

Answer 4

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

актив.рб:

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

аватар.рб:

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

pdf.rb:

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

Answer 5

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

Я собираюсь добавить это в свое приложение с помощью 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 и больше не поддерживается.Хотя это было красиво и просто...Эх, старые добрые времена...

Answer 6

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

http://gist.github.com/33011