¿Cómo organizar los modelos de Rails demasiado gordos?

Question

Es una buena práctica cambiar la lógica del controlador al modelo. Pero en cualquier sistema complejo, esto conduce invariablemente a un archivo muy grande, incluso si la mayoría de los métodos son de una sola línea según Rails Way.

He recurrido a dividir los modelos en otros módulos e incluirlos en el modelo original, por ejemplo, model_flags, model_validation, etc. ¿Alguien tiene una manera mejor?

Editar: He seleccionado una nueva respuesta que sugiere el uso de ActiveConcern. Además, para cualquier persona que esté interesada en organizar el código, este artículo, Making ActiveRecord Models Thin, debería ser de gran ayuda.

Answer 1

Me di cuenta de esto es una pregunta bastante antigua y ha sido marcada como respondida, pero todavía tiene un buen jugo de Google, así que pensé que valía la pena agregar a ...

Rails 3 presentó ActiveSupport :: Concern, que se puede usar para modularizar el comportamiento eso se comparte entre los modelos. O, para el caso, adelgazar modelos que se han vuelto demasiado gordos.

DHH mismo proporciona un agradable, sucinta ejemplo GIST aquí:

https://gist.github.com/1014971

Answer 2

Los módulos suena sensato. No extraería las llamadas a métodos (validaciones, devoluciones de llamada, complementos, etc.) en módulos, sin embargo, limitaría la extracción a mis propios métodos.

Y, como siempre, sería útil si publicara algún código de muestra. Me resulta difícil imaginar una estrategia genérica para limpiar modelos, depende de la naturaleza del código.

Answer 3

No haría esto por algunas razones.

Primero viola la suposición de que las cosas estarán donde deberían estar, lo cual es probablemente la mayor ventaja para los rieles en primer lugar. Una nueva persona puede caminar sobre su proyecto y navegarlo con bastante facilidad si pega material modelo en su modelo. Si lo saca, solo agrega un retraso y algo de confusión, especialmente si la única lógica para eliminar algo de un módulo es reducir el tamaño del modelo.

Segundo, no ganas casi nada y pierdes algo. El tamaño del archivo no importa en estos días cuando casi todos los editores e IDE alivian el dolor de navegación de los archivos de gran tamaño. Mover cosas a un módulo en realidad quita parte de esta facilidad moderna y requerirá que usted y sus colegas o futuros mantenedores salten varios archivos más mientras trabajan en un modelo.

Dicho esto, sospecho que lo que la mejor práctica de los rieles duros le dirá es que si su modelo es tan grande y complejo, su diseño es defectuoso y su modelo probablemente represente varias cosas que podrían convertirse en modelos separados en lugar de módulos.

Answer 4

No tener conocimiento de su modelo de objeto, es un poco más difícil de aconsejar, pero diría que si está absolutamente convencido de que todas las validaciones/asociaciones/devoluciones de llamada necesitan para estar en ese lugar, hay todavía hay maneras de factorizar comportamientos comunes. Entonces, si bien no solo movería una gran porción de código de un archivo a otro, sino que volvería a abrir la clase, diría que es una buena idea usar módulos/complementos para describir los tipos comunes de comportamientos.

Por ejemplo, si está creando un feed de actividad de Facebook, y todo tiene que generar "eventos", entonces quizás desee mover ese comportamiento "Evitable" a un módulo, que cuando se incluye, define las asociaciones/validaciones/etc. Diría que ese enfoque en realidad mejoraría la claridad de tu código, ya que especificar manualmente esas asociaciones en todas partes no es tan expresivo como declarar algo como Evitable, ni tampoco es tan seguro (estarías duplicando la lógica en un montón de lugares , y cuando la lógica cambia, usted sabe el resto ...)

En general, yo diría que eche un vistazo a su modelo de objetos. En su suite de pruebas, si observa que todas sus pruebas requieren mucha configuración, puede ser un buen indicador de que le falta algo en su modelo de objetos. De nuevo, un código de muestra sería genial.

Answer 5

Bueno, no diría que ninguno de ustedes está equivocado al poner todo en un modelo, pero creo que también es bastante válido para poder separar varias preocupaciones. Es una compensación en lo mínimo.

Y les dejo una respuesta a mi propia pregunta, como he encontrado el Camino rieles de hacer precisamente eso: http://github.com/jakehow/concerned_with

Más información se puede encontrar aquí: http://m.onkey.org/2008/9/15/active-record-tips-and-tricks

Answer 6

• puede utilizar objetos de servicio: http://railscasts.com/episodes/398-service-objects
• También puede utilizar preocupaciones. Se crea una carpeta para ella de forma predeterminada en los rieles 4: http://railscasts.com/episodes/400-what-s-new-in-rails-4