ruby on rails - pcloud - ¿Dónde está el mejor lugar para almacenar los parámetros de la aplicación: base de datos, archivo, código...?

nube virtual gratis

Question

Estoy desarrollando un sitio web de Ruby on Rails y tengo una pregunta "arquitectónica": mi aplicación necesita algunos parámetros y me pregunto dónde almacenarlos.

En términos concretos, mi aplicación recibe algunas solicitudes que son evaluadas y luego enviadas. Por lo tanto, el modelo de Solicitud debe tener atributos relacionados con estos tratamientos: un estado de validación y un estado de envío . Por ejemplo, el estado de validación puede ser " aceptado ", " rechazado " o "en espera ". El estado de envío puede ser " enviado ", " esperando ", " error durante el envío " o cosas así. Tengo que almacenar esos parámetros de códigos de estado en algún lugar, pero no sé cuál es la mejor solución.

Podría crear un modelo para cada uno y almacenarlos en la base de datos (y tener un modelo de registro activo ValidationStatus por ejemplo) pero: ¿no sería excesivo crear una base de datos / modelo para almacenar datos como ese?

También podría usarlos en el código sin "almacenarlos", podría almacenarlos en un archivo YAML ...

Entonces, una pregunta más simple: ¿cómo manejas los parámetros de tu aplicación en RoR?

Answer 1

Hay muchos complementos de configuración global, la mayoría de ellos giran en torno a la idea de cargar un archivo YAML en algún momento. Compruebe esta página , este complemento e incluso este Railscast .

Answer 2

Los puse en la base de datos. Tengo muchos de estos, y todos son listas bastante simples de cadenas. Las tablas son todas iguales: identificación, nombre, descripción.

Genero modelos para ellos en lugar de tener un archivo de modelo real para cada uno. En la aplicación / modelos tengo un archivo llamado active_record_enums.rb, que en su caso se vería así:

ACTIVE_RECORD_ENUMS = %w{
  ValidationStatus
  SendingStatus
}

ACTIVE_RECORD_ENUMS.each do |classname|
  eval "class #{classname} < ActiveRecord::Base; end"
  classname.constantsize.class_eval do 
    # Add useful methods - id_for(name) and value_for(id) are handy
  end
end

Este archivo debe ser requerido en un archivo de configuración en alguna parte; aparte de eso, es bastante sencillo.

Answer 3

No estoy usando Ruby, pero le diré que comencé (en ASP.NET) colocando muchas configuraciones en un archivo Web.Config (similar a un YAML). Sin embargo, a medida que pasó el tiempo, el sistema evolucionó hasta el punto en que diferentes instancias necesitaban configuraciones diferentes. Entonces, casi todos ellos migraron a la base de datos. Entonces ... si va a implementar varias instancias de su sitio, le recomiendo mantener la configuración en una tabla de su base de datos (la mía tiene solo un registro, con campos para varias configuraciones). Si hubiera hecho esto para comenzar, habría ahorrado una cantidad significativa de tiempo.

Answer 4

Tiendo a hacer una columna de string para cada uno, y uso validates_inclusion_of para establecer lo que es aceptable para ellos.

class Request < ActiveRecord::Base
  validates_inclusion_of :validation_status, :in => [''accepted'',''rejected'',''waiting'']
  validates_inclusion_of :sending_status, :in => [''sent'',''waiting'',''...'']
end

Si necesita que sucedan cosas (es decir, correos electrónicos enviados) cuando el estado cambia, investigue usando el plugin Acts As State Machine para administrarlo.

Answer 5

(Desde entonces, he visto el reparto de rieles mencionado anteriormente [episodio 85] - parece un poco más ''el camino de los rieles'' que a continuación)

Otro enfoque es construir sobre el mecanismo de configuración existente en Rails. Supongamos que hay dos tipos de configuraciones:

1. Amplias configuraciones de la aplicación comunes a entornos dev / test / prod
2. Configuraciones específicas para envrionments dev / test / prod

Para el primer escenario, los elementos en "RAILS_ROOT + ''/config/environment.rb''" funcionan. Solo vea que los nombres están capturados por lo que son constantes de Ruby. Una variación de esto es tener una referencia a otro archivo en ese archivo environment.rb ...

require RAILS_ROOT + ''/config/appConfigCommon.rb''

y coloque elementos de configuración relevantes en ese archivo. Esto tiene la ventaja de poder ser referenciado independientemente de Rails.

Para el escenario 2, se puede tomar un enfoque similar. Coloque los elementos para el desarrollo en "RAILS_ROOT + ''/config/environments/development.rb''" o algo así como

require RAILS_ROOT + ''/config/environments/appConfigDev.rb''

y coloque elementos específicos del entorno en ese archivo requerido, asegurándose de que comiencen con mayúsculas. Y siga el mismo patrón para prueba / prod (y otros si es necesario).

Los ítems de configuración son directamente accesibles en vistas y controladores (no estoy seguro acerca de los modelos) simplemente usando el nombre de la constante.