update tutorial rails generate foreign create and ruby-on-rails model

ruby on rails - tutorial - ¿Cómo organizar los modelos de Rails demasiado gordos?



ruby on rails tutorial (6)

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 mejor manera?

Editar: seleccioné una nueva respuesta que sugería usar ActiveConcern. Además, para cualquier persona que esté interesada en organizar el código, este artículo, Hacer que los modelos ActiveRecord sean delgados , debería ser de gran ayuda.

Me doy cuenta de que esta 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 que se comparte entre los modelos. O, para el caso, adelgazar modelos que se han vuelto demasiado gordos.

El propio DHH proporciona una buena y sucinta muestra de ejemplo aquí:

https://gist.github.com/1014971

Al 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 deben estar en ese lugar, 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 al estilo Facebook, y todo necesita generar "eventos", entonces tal vez 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, sabes el resto ...)

Sin embargo, en general, 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.

Los módulos suenan sensatos. 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 que publicaras 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.

No haría esto por algunas razones.

Primero violas la suposición de que las cosas estarán donde deberían estar, lo que 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 plataforma de mejores prácticas de los rieles duros le dirá es que si su modelo es tan grande y complejo, entonces su diseño es defectuoso y su modelo probablemente represente varias cosas que podrían convertirse en modelos separados en lugar de módulos.