ruby on rails - Rieles-Donde(directorios) para poner Modelos que no son Registro Activo

ruby-on-rails activerecord

Question

Estamos construyendo aplicaciones que tienen modelos que no son componentes de base de datos. Tenemos curiosidad por saber qué hacen los demás en la comunidad de ferrocarriles para abordar este tema.

Estamos luchando con dónde colocarlos.

Debemos tener:

app/models/domain

o

app/domain/models

o quizás

app/models # Business Models
app/models/ar # Active Record Models

o quizás

app/models/domain/ # Business Models
app/models/domain/ar # Active Record Models

Parte de esto es que estamos luchando contra cuán cerca de estar de los estándares de rieles y cuánto crear una estructura que será buena para lo que necesitamos.

Si pensamos en los objetos como objetos de servicio, podríamos tener

app/models/service-object

y

app/models/ # For plain active record

Otra ruta para bajar no es tener cosas dentro de la aplicación, por ejemplo,

/service_objects

en lugar de

/app/models/service_objects

Presumiblemente, si queremos acceder a través de una aplicación Rails, es mejor que usemos app / para aprovechar las convenciones sobre la configuración.

Answer 1

En mi experiencia, la división de dónde colocas estos modelos se reduce a lo que representan funcionalmente en el contexto específico de tu aplicación.

Normalmente reservo app/models para modelos basados ​​en recursos. Si ese modelo representa un recurso que está instanciado y manipulado por su aplicación, vaya aquí. No necesita estar respaldado por AR o db.

Si el modelo tiene una funcionalidad consistente pero varía en los parámetros, les doy un directorio de nivel superior en la aplicación. Sin embargo, si tiene un recurso que requiere un observador, es posible que no tenga sentido tener un directorio de app/observers con un solo archivo.

Todo lo demás va en lib . Hay algunas razones por las que esto es preferible.

1. Puede elegir cuándo solicitar los archivos en lib . Puede ser mucho más selectivo sobre qué archivos se cargan cuando se inicia la aplicación. Si pones todo en la app/models no tienes granularidad sobre lo que se carga.

2. El espacio de nombre de sus modelos a medida que su aplicación crece es más fácil en lib. Claro que puedes crear espacios de nombres en app/models pero varias capas de anidamiento en app/models siempre terminan desagradables. Es mejor mantener el espacio de nombres en lib .

3. La limpieza se hace mucho más fácil cuando tienes las cosas en su lugar funcionalmente correcto. ¿No es un recurso? ¿No es un observador? Debe estar en lib . La razón principal por la que está pensando en esto desde el principio es proporcionar descubrimientos a los desarrolladores en el futuro.

Answer 2

Para los objetos de servicio, normalmente los tendrá directamente en el directorio de app/services/ . Los trabajadores y los serializadores también siguen este patrón app/workers/ app/serializers/ . En cuanto a sus modelos que no son AR, todavía puede pegarlos en el directorio de modelos. Esa es mi opinión.

Answer 3

Si son modelos, debe ponerlos en app/models ya que este directorio está diseñado para modelos y no solo para subclases ActiveRecord.

Answer 4

Si tiene clases que no son modelos, por ejemplo, tal vez representan un formulario, yo diría que siga adelante y las ponga en lib .

Si son ortogonales a su aplicación, es decir: es una interfaz que se usa para llamar a otra aplicación, puede envolverla como una gema privada o pública en función de su aplicabilidad al resto de la comunidad.

Al final, realmente no importa. Elige una cosa y ponte de acuerdo con el resto de tu equipo. Mover cosas debe ser bastante fácil, especialmente si agrega lo que decida usar a la ruta de carga para su aplicación ( $LOAD_PATH += ''...'' ).