Dónde poner los métodos reutilizables para el acceso de los controladores en los rieles

Question

Tengo varios métodos que llamo desde mis controladores que se sienten como si fueran extraídos y colocados en una clase reutilizable, fuera del controlador. ¿Dónde la gente suele poner estas cosas? Sé que puedo ponerlos en mi ApplicationController, pero esa no parece ser una gran solución si creo que puedo usar estos métodos más adelante en otras aplicaciones.

Además, tengo un montón de métodos de utilidad en mis controladores que probablemente no se utilizarán en otros controladores, o en el futuro en absoluto, pero siento que simplemente inflan un poco mi controlador. Por lo general, ¿las personas los trasladan a algún lugar para la limpieza o acaban teniendo un gran controlador?

Vengo de Java y Actionscript donde solo crearía nuevas clases de utilidades para este material.

Answer 1

El directorio lib es un lugar donde puede colocar módulos/clases que pueden ser mezclados o utilizados por los controladores (y cualquier otra cosa, en realidad). Este puede ser un lugar para poner el código que no cae en otras áreas (pero tenga cuidado de asegurarse de que la lib no se convierta en un desastre). comentarios secundarios sólo para tener en cuenta:

• Si usted sabe que tiene una gran cantidad de funcionalidades relacionadas que podrían, o que, usarse en otras aplicaciones, que podría ser un plugin.

• También vale la pena tener en cuenta que no hay nada de malo en crear un modelo que no sea un objeto de registro activo. De nuevo, dependiendo de lo que tenga, esto también podría tener sentido.

Answer 2

Crear un archivo de módulo en lib directorio:

module ControllerUtil 
    def foo 
    end 

    def bar 
    end 
end 

incluir el módulo en el controlador:

class UsersController < ApplicationController 
    include ControllerUtil 
end 

Answer 3

controladores deberían ser muy mínimo - básicamente la ingestión de argumentos y hacer algo muy alto decisiones de nivel. Si tiene algunas funciones de ayuda que solo hacen ese tipo de cosas pero no las van a reutilizar, entonces mantenerlas en el controlador es lo correcto. Solo asegúrate de marcarlos como privados.

Para elementos compartidos con más frecuencia, puede hacer una copia de seguridad en su ApplicationController (si se usan en todos los controladores) o en una clase en el directorio de su aplicación/modelos. Recomiendo el directorio de modelos sobre lib porque Rails en modo de desarrollo es mucho mejor para detectar cambios en esos archivos y volver a cargarlos. Los cambios en los archivos en/lib tienden a requerir el reinicio del servidor web, lo que ralentiza su esfuerzo de desarrollo. Esto es desafortunado, porque los ayudantes de los controladores realmente no deberían mezclarse con los modelos.

En general, sin embargo, si tiene más de un puñado de estos ayudantes, probablemente esté haciendo demasiado en sus controladores. Mírelos detenidamente y vea si tal vez algunos de ellos no deberían ser parte de sus modelos.

Answer 4

Puede crear app/modules directorio, y crear el módulo XYZUtils en ella por ejemplo

module XYZUtils 
    def abc 
    end 

    def efg 
    end 
end 

e incluir el módulo como y cuando sea necesario en los controladores y los modelos etc.

include XYZUtils 

Se pueden crear diferentes módulos para funciones de utilidad relacionados con diferentes modelos o entidades

No voy a preferir /lib directorio debido a que debe contener el código relacionada con el proyecto, no aplicación relacionada, por ejemplo, tareas, etc.

me gustaría mantener todo el código relacionado App en /app propio directorio

Answer 5

en relación con la respuesta anterior de Sahil kalra a partir de 2014:

Rails ahora tiene un directorio app/controllers/concerns donde puede colocar módulos llenos de métodos de ayuda e incluirlos o ampliarlos fácilmente en sus controladores. Acabo de copiar y pegar todos mis métodos de uso intensivo de lógica fuera de mi application_controller y funcionaron inmediatamente.

(Usted debe, por supuesto, todavía asegurarse de que todo funciona correctamente antes de poner cualquier cosa en la producción.)