Где лучше всего хранить параметры приложения: базу данных, файл, код ...?

Question

Я занимаюсь разработкой веб-сайта на Ruby on Rails, и у меня возник «архитектурный» вопрос: моему приложению нужны некоторые параметры, и мне интересно, где их хранить.

Конкретно, моя заявка получает некоторые запросы, которые оцениваются, а затем отправляются. Таким образом, модель запроса должна иметь атрибуты, относящиеся к этим процедурам: статус проверки и статус отправки . Например, статус проверки может быть " принят ", " отклонен " или " ожидает ". Состояние отправки может быть " отправлено ", " ожидание ", " ошибка при отправке " или тому подобное. Мне нужно где-то хранить параметры этих кодов состояния, но я не знаю, какое решение лучше.

Я мог бы создать модель для каждой из них и сохранить их в базе данных (например, с активной моделью записи ValidationStatus), но не слишком ли утомительно создавать базу данных / модель для хранения подобных данных?

Я мог бы просто использовать их в коде, не "сохраняя" их, я мог бы хранить их в файле YAML ...

Итак, более простой вопрос: как вы справляетесь с параметрами вашего приложения в RoR?

Answer 1

Существует множество глобальных плагинов конфигурации, большинство из которых вращаются вокруг идеи загрузки файла YAML в какой-то момент. Проверьте эту страницу , этот плагин и даже этот Railscast .

Answer 2

Я положил их в базу данных. У меня их много, и все они довольно простые списки строк. Таблицы все одинаковые - идентификатор, имя, описание.

Я генерирую модели для них, а не фактический файл модели для каждой. В app / models у меня есть файл active_record_enums.rb, который в вашем случае будет выглядеть примерно так:

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

Этот файл должен быть где-то в конфигурационном файле; кроме этого это довольно просто.

Answer 3

(С тех пор видели, что рельсы брошены, упомянутые выше [эпизод 85] - это выглядит немного больше "пути рельсов", чем ниже)

Другой подход заключается в использовании существующего механизма конфигурации в Rails. Предположим, есть два типа конфигов:

1. Широкие конфиги приложения, общие для сред dev / test / prod
2. Конфиги, специфичные для среды dev / test / prod

Для первого сценария элементы в "RAILS_ROOT + '/config/environment.rb'" работают. Просто посмотрите, что имена запечатлены, поэтому они являются константами Ruby. Вариантом этого является ссылка на другой файл в этом файле environment.rb ...

require RAILS_ROOT + '/config/appConfigCommon.rb'

и поместите соответствующие элементы конфигурации в этот файл. Преимущество заключается в возможности ссылаться независимо от Rails.

Для сценария 2 может быть использован аналогичный подход. Поместите элементы для разработки в "RAILS_ROOT + '/config/environments/development.rb'" или что-то вроде

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

и поместите элементы, относящиеся к среде, в этот требуемый файл, убедившись, что они начинаются с заглавных букв. И следуйте той же схеме для теста / продукта (и других, если это необходимо).

Элементы конфигурации доступны напрямую в представлениях и контроллерах (не уверены в моделях), просто используя постоянное имя.

Answer 4

Я, как правило, просто делаю столбец string для каждого и использую validates_inclusion_of, чтобы установить то, что приемлемо для них.

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

Если вам нужно, чтобы что-то происходило (например, отправлялись электронные письма) при изменении статуса, используйте для управления им плагин Acts As State Machine .

Answer 5

Я не использую Ruby, но я скажу вам, что я начал (в ASP.NET) помещать множество настроек в файл Web.Config (аналогично YAML). Однако со временем система развилась до такой степени, что разные экземпляры нуждались в разных настройках. Таким образом, почти все они мигрировали в базу данных. Итак ... если вы будете развертывать несколько экземпляров своего сайта, я настоятельно рекомендую сохранить настройки в таблице вашей базы данных (у меня есть только одна запись с полями для различных настроек). Если бы я сделал это для начала, я бы сэкономил значительное количество времени.