Дизайнерский вопрос для проекта Ruby on Rails

#ruby-on-rails #ruby #class #web-applications

#ruby-on-rails #ruby #класс #веб-приложения

Вопрос:

Я начинаю работать над новым приложением Ruby on Rails, которое представляет собой CRUD-интерфейс для определенных атрибутов, содержащихся в файле конфигурации. Процесс будет выглядеть примерно так: CRUD RoR App > База данных> Экспорт в файл конфигурации.

Мой вопрос заключается в том, каков оптимальный способ проектирования этого (серверная часть, которая экспортирует из базы данных в файл конфигурации). Предполагая, что файл конфигурации находится на том же сервере, что и приложение RoR, могу ли я просто написать отдельные классы (в / lib), у которых есть методы для чтения / записи в файл конфигурации и включения / вызова их в фильтр before_create в моих моделях?

Ответ №1:

Это действительно плохая идея создавать приложение, которое изменяет себя при запросе с помощью пользовательского ввода. Это сводит на нет преимущества контроля версий и приводит к множеству запутанных ошибок.

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

Еще одна вещь, которую следует иметь в виду, это то, что определения классов Ruby выполняются точно так же, как обычный код. Например, вы можете сделать следующее:

 class Foo
  if RUBY_VERSION == '1.9.2'
    def self.bar
      # do something 1.9.2 style
    end
  else
    def self.bar
      # do something 1.8.7 style
  end
end
  

В этом примере показан более распространенный переключатель Ruby-version, но вы можете сделать то же самое на основе значений конфигурации, если они доступны приложению при выполнении определения класса. Если у вас есть load класс, в котором вы это делаете, вы всегда можете load повторить это снова, если / когда значения конфигурации изменятся, чтобы получить это преимущество.

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

Имеет смысл?

Комментарии:

1. Что заставляет вас думать, что файл конфигурации предназначен для приложения rails?

2. Я понимаю, что вы имеете в виду, но файл конфигурации предназначен для сторонних приложений (не Rails).

Ответ №2:

Да, вы можете просто рассматривать ConfigFile как класс модели, который не использует ActiveRecord. Он может сочетаться с вашими другими моделями (не обязательно входить в / lib).

 class ConfigFile #note no inheriting from AR::Base

  def import
    ...
  end

  def export
    ...
  end
end
  

Этот класс может быть интерфейсом к файлу, используемому вашим приложением Rails. Хотя я не уверен насчет вызова его из before_create. Если вы планируете каждый раз восстанавливать весь файл целиком, вам не хотелось бы делать это, когда обновляется только одна его часть, если только она не очень маленькая.

Есть ли у вас возможность определить формат файла конфигурации? Просто выведите model.to_yaml и все готово!

Комментарии:

1. Это конфигурационный файл Postfix (обычный текст). Итак, я бы не хотел каждый раз восстанавливать файл — просто добавляйте / удаляйте его части.