Rieles: ¿Cuándo un modelo? Cuando una lib?

Estoy haciendo un pequeño módulo de envío de mensajes. Se encargará de que los mensajes de colas de una solicitud sean recogidos por un trabajador de segundo plano para enviar correos electrónicos/SMS (o registrarlos apropiadamente para las pruebas).Rieles: ¿Cuándo un modelo? Cuando una lib?

Pregunta: este es un Modelo (en/app/modelos) o una lib (en/lib).

me gustaría alguna religión en esto.

Teoría A: (Mi teoría actual) A menos que esté subclasificando ActionMailer :: Base o ActiveRecord :: Base, etc., su código debe entrar en lib.

Teoría B: (Teoría hacia la que me inclino) Las cosas que son específicas de la aplicación deben estar en el modelo. Todo lo que podría ser de uso general debería estar en lib.

Teoría C: solo los "modelos de datos" deben estar en 'modelos'. Las subclases de ActionMailer rompen esta regla, sin embargo.

Por lo que yo sé, de cualquier manera funcionará bien, pero estoy buscando razones funcionales o filosóficas sutiles para una u otra.

¿Pensamientos?

Fuente

2009-11-02 Kevin Moore

Estoy de acuerdo con usted:. Si no hereda de ActiveRecord y co, que no debería ser un modelo. No tengo suficiente que decir para convertir esa opinión en una respuesta completa. ^^ – marcgg

Independientemente de si los mensajes se heredan de ActiveRecord o ActionMailer, es probable que desee un modelo para cualquier objeto con el que sus vistas y controladores interactúen. En su caso, manejarán las instancias de la clase Message; usted quiere un modelo para eso.

En cuanto al módulo de envío de mensajes, extraer a una biblioteca es genial si planea reutilizar el código en otro lugar donde puede simplemente incluir el módulo en cualquier clase.

Dado que este es solo un módulo de envío de mensajes "pequeño", es posible que desee comenzar en el modelo y eventualmente extraerlo en un módulo separado si puede ser útil en otro lugar o si su modelo se vuelve demasiado complicado.

Fuente

2009-11-02 01:08:37 bensie

¿Cree que este mapa de la Teoría B anterior? –

Sí, su teoría B es correcta. Sin embargo, en la mayoría de los casos, aún desea un modelo para algo que puede no ser específico de la aplicación. Tome por ejemplo una clase de mensaje. Sí, puedes interactuar con mensajes en varias aplicaciones diferentes de la misma manera, pero casi siempre habrá ocasiones en las que desees anular o personalizar el comportamiento del mensaje por aplicación. Entonces, crea el modelo en todas las aplicaciones y haz que incluya las lib (s). – bensie

probablemente debería pensar más en términos de negocio subyacente aquí. Los modelos, como su nombre lo sugiere, están aquí para representar (modelar) algún sistema o proceso del mundo real. Entonces, la regla general debería ser esta: ¿esta entidad juega algún papel en el sistema que estoy tratando de expresar en mi aplicación? Si la respuesta es positiva, la entidad es un buen candidato para ser un modelo. Sin embargo, sería perfectamente correcto implementar la funcionalidad principal de su módulo de mensajería en una biblioteca separada para su posterior reutilización y simplemente incluirla en el modelo.

Fuente

2009-11-02 01:15:27

¿Cree que este mapa de la Teoría B anterior? –

Me gusta la teoría de 'Modelo de datos' y trato de atenerme a ella cuando puedo, pero creo que Bensie y Milán tienen la idea correcta. Si tiene vistas y controladores asociados, debería ser con modelos. Si solo hace referencia a la funcionalidad desde otra clase, colóquela en la lib.

Fuente

2009-11-03 19:29:53 cgr

Rieles: ¿Cuándo un modelo? Cuando una lib?

Respuesta

Cuestiones relacionadas