rieles + clip de papel: ¿Es una buena idea un modelo genérico de "archivo adjunto"?

Question

En mi aplicación tengo varias cosas con archivos adjuntos, usando paperclip.

• Los clientes tienen un logotipo.
• Las tiendas pueden tener una o más imágenes. Estas imágenes, además, pueden tener otra información , como la fecha en que fueron tomadas.
• Los productos pueden tener una o más imágenes de ellos, categorizados (desde la fuente, desde el hacia atrás, etc.).

Por ahora, cada uno de mis modelos tiene su propio "paperclip campos" (has_attached_file cliente) o modelos has_many que se han adherido archivos (StorePictures tienda has_many, ProductPictures has_many productos)

Mi cliente tiene también me dijo que en el futuro podríamos estar agregando más archivos adjuntos al sistema (es decir, documentos PDF para que los clientes descarguen).

Mi aplicación tiene un sistema de autorización bastante complejo implementado con declarative_authorization. Uno no puede, por ejemplo, descargar imágenes de un producto que no tiene permitido 'ver'.

Estoy considerando volver a factorizar mi código para que pueda tener un modelo genérico de "Archivo adjunto". Entonces cualquier modelo puede has_many :attachments.

Con este contexto, ¿suena como una buena idea? ¿O debería continuar haciendo Foos y FooPictures?

Answer 1

He encontrado que a menudo hay casos en que una clase genérica de archivo adjunto es mucho más fácil de administrar que los archivos adjuntos independientes en otros tipos de registros. El único inconveniente del enfoque simple de Apego es que las miniaturas que se deben producir se definen para todos los posibles archivos adjuntos simultáneamente en lugar de caso por caso.

Un enfoque híbrido que permite una mayor flexibilidad es crear una tabla de datos adjuntos basada en ITS mediante la inclusión de una columna 'tipo' y crear subclases específicas de uso como ProductAttachment que define estilos específicos.