在 Ruby on Rails 应用程序中尽可能保持 DRY
-
09-06-2019 - |
题
我目前正在为 Rails 应用程序使用很棒的 Attachment-fu 插件,但作为一名新手开发人员,我从未遇到过像我遇到的情况。
本质上,我在两个层面上使用attachment-fu 插件。
- 用于用户类别中的用户头像。
- 是允许文件附件(PDF 文件, 等)在消息系统中。
我的问题是,在这些情况下,最好的使用实践是什么? 干燥, 、清晰、一致。
显然,在这两个类中定义和执行插件是没有意义的,但是对于我来说,在神圣的 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 插件处理多个附件方面做得很好。他在这里概述了他的工作: