ruby-on-rails - que - ruby on rails software

directrices sobre dónde colocar clases en las aplicaciones de Rails que no se ajustan a ningún lado

Question

Me pregunto si hay algunas prácticas recomendadas sobre dónde colocar archivos Ruby no estándar en las aplicaciones de Rails, aquellos que no encajan en ninguno de los directorios predeterminados ( controllers / models etc.).

Estoy hablando de las clases que usan los controladores / modelos, etc., pero no son subclases de ninguna de las clases base de Rails. Clases que incluyen la funcionalidad extraída de los modelos para hacerlos menos gordos. Algunos de ellos parecen modelos pero no son modelos AR, algunos se parecen más a "servicios", algunos son algo intermedio o algo más.

Algunos ejemplos al azar:

• Clases de "estrategia" que manejan la autenticación con contraseña, a través de Facebook, etc.
• Objetos "XParams" que encapsulan params o objetos "XCreator" que manejan el procesamiento de params para ejecutar alguna acción compleja que da como resultado la creación de algunos modelos AR al final
• clases que realizan solicitudes a API externas o que encapsulan esas solicitudes y respuestas
• modelos falsos que pueden ser sustituidos por un modelo AR real (por ejemplo, usuario invitado)
• Trabajos de Resque
• clases que almacenan y leen información de Redis
• clases que ejecutan algunas acciones específicas, como procesamiento de datos, generación de informes, etc. y se llaman desde trabajos de Resque o tareas de rastreo

Tengo muchos de estos ahora, algunos de ellos se agregan a lib que termina en una pila de clases y módulos aleatorios, algunos se cuelan en las app/models . Me gustaría organizar esto de alguna manera, pero no sé por dónde empezar.

¿Deberían solo los modelos AR entrar en la app/models ? ¿O está bien poner también algún dominio o modelos de ayuda? ¿Cómo decides si algo es un modelo?

¿Debería todo lo que no encaja en la app entrar en lib ? ¿O tal vez debería agregar algunos nuevos subdirectorios personalizados a la app ? ¿Qué subdirectorios, y cómo divido las clases personalizadas?

¿Cómo manejas esto en tus proyectos? Sé que cada proyecto es un poco diferente, pero debe haber algunas similitudes.

Answer 1

A menudo mis clases encuentran su camino en lib en subdirectorios donde los módulos con el mismo nombre que el subdirectorio son responsables de incluirlos. (Rails es muy delicado con respecto a nombres de archivos y nombres de clase cuando se trata del autocargador).

Otra opción es encapsular cada módulo en su propia gema y luego referirse a la gema a través de su Gemfile. Esto permite el intercambio de código entre proyectos.

Answer 2

Buena pregunta: no tengo una respuesta concreta para ti

pero recomiendo ver esta publicación - http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-in-the-lib-directory/ - asegúrese de leer todos los comentarios

en un proyecto actual, tengo una tonelada de objetos que no son ActiveRecord en la aplicación / modelos, funciona pero no es ideal. Puse el código no aplicable a la aplicación no reutilizable bajo lib

otras alternativas que he probado en proyectos secundarios (digamos que tenemos un montón de objetos de comando) rails es un dolor cuando se trata de espacios de nombres en la aplicación, carga todo en el mismo espacio de nombres de forma predeterminada

app/
  commands/
    products/create_command.rb         # Products::CreateCommand
    products/update_price_command.rb   # Products::UpdatePriceCommand

alternativo, todo además de los rieles bajo src o un directorio de nombre de aplicación

app/
  src/
    commands/
      create_product.rb         # Commands::CreateProduct
      update_product_price.rb   # Commands::UpdateProductPrice

No he encontrado una buena solución para esto, idealmente la segunda es mejor, pero sería bueno no tener el directorio adicional bajo la aplicación, de esa manera abrir la aplicación y ver los controladores, comandos, modelos, etc ...

Answer 3

Coloco cualquier clase de modelo (como las subclases de STI) en apps/models . Coloco mis otras clases en lib , ya que parece ser el mejor lugar para ponerlas. Es fácil para mí saber dónde mirar. También es más fácil para mí agrupar mis pruebas ya que mis clases modelo están todas en un solo lugar.

En lo que concierne a la convención, detestaba poner clases de ayuda en app/models . Si son clases de presentador, pertenecen a la app/helpers . Si no lo están, entonces lib parece ser el mejor lugar para ellos.

Answer 4

Si está interesado, también escribí un artículo de seguimiento sobre esto un poco más tarde, resumiendo lo que encontré: blog.lunarlogic.io/2013/declutter-lib-directory

Answer 5

Tocas varios casos de uso diferentes y creo que esta parte es la más cercana a la respuesta "correcta":

Tengo muchos de estos ahora, algunos de ellos se agregan a lib, que termina en una pila de clases y módulos aleatorios, algunos se cuelan en las aplicaciones / modelos. Me gustaría organizar esto de alguna manera, pero no sé por dónde empezar.

Eso es más o menos en mi libro. Lo único que no mencionas es extraer varias piezas en gemas separadas. Las clases que hablan con servicios externos son excelentes candidatos para la extracción, al igual que las clases de estrategia si son suficientemente generales. Estos pueden ser privados, ya que ejecutar su propio servidor de gemas no es difícil, y luego, obviamente, puede reutilizarlos en las aplicaciones de ROR.

Último y más concretamente, resquebra los trabajos que llevo en lib / jobs.

Mi regla de oro es si es un modelo de algún tipo , se aplica a la app/models . Si no es así, probablemente pertenezca a lib o a algún subdirectorio con el nombre apropiado, por ejemplo, lib/jobs , lib/extensions , lib/external , o similar.