在我的应用程序中,我使用paperclip在附件上添加了几个附件。
目前,我的每个模型都有自己的“paperclip-fields”(Client has_attached_file)或has_many模型,附带文件(Store has_many StorePictures,Product has_many ProductPictures)
我的客户还告诉我,将来我们可能会在系统中添加更多附件(即客户下载的pdf文档)。
我的应用程序使用declarative_authorization实现了相当复杂的授权系统。例如,人们无法从他不允许“看到”的产品中下载图片。
我正在考虑重新分解我的代码,以便我可以使用通用的“附件”模型。所以任何模型都可以has_many :attachments
。
有了这个背景,这听起来像个好主意吗?或者我应该继续制作Foos和FooPictures吗?
答案 0 :(得分:5)
我发现通常情况下,通用附件类比各种其他类型的记录上的独立附件更容易管理。简单附件方法的唯一缺点是需要生成的缩略图是为所有可能的附件同时定义的,而不是根据具体情况。
允许更大灵活性的混合方法是创建基于STI的附件表,方法是包含“类型”列并创建特定于用途的子类,例如定义特定样式的ProductAttachment。