Настройки загрузки - лучшие практики
Я нахожусь в точке своего первого реального приложения, где я добавляю в пользовательские настройки. Я использую Java и очень OO (и пытаюсь сохранить его таким образом), вот мои идеи:
- Загрузите все в
main() и
передайте все "вниз по линии" на
требуемые объекты (массив)
- То же, что и выше, но просто передайте
объект, содержащий данные вниз
строка
- Загрузите каждую отдельную настройку в качестве
необходимых в различных классах.
Я понимаю некоторые основные плюсы и минусы каждого метода (т.е. время и размер), но я ищу некоторые внешние данные о том, какие методы они успешно использовали в прошлом.
Ответы
Ответ 1
Так как конфигурация/настройки обычно загружаются один раз (при запуске или, возможно, несколько раз во время выполнения программы. В любом случае мы не говорим о очень частом/трудоемком процессе), я бы предпочел простоту эффективность.
Это исключает номер опции (3). Конфигурационная загрузка будет разбросана повсюду.
Я не совсем уверен, в чем разница между (1) и (2) в вашем списке. Имеет ли (1) "прохождение секретных параметров" и (2) означает "передача объекта, содержащего всю конфигурацию"? Если это так, я бы предпочел (2) более (1).
Эмпирическое правило заключается в том, что вы должны держать вещи простыми и сконцентрированными. Преимущество конфигурации чтения в одном месте состоит в том, что он дает вам лучший контроль в случае, если источник конфигурации изменится в какой-то момент.
Ответ 2
Кто-то должен отстаивать предполагаемый стандарт Java, API настроек... и это последнее воплощение в JDK6. Отредактировано для добавления, так как автор, похоже, подкован XML, это больше чем раньше. Думаю, я верю, что вы можете работать с XML juju с Properties, если дух возьмет вас.
Относительно SO: API предпочтений по сравнению с решением Apache, Является ли класс основных предпочтений хорошей идеей?
(хорошо, что обо всем стоящем я готов сделать.)
Ответ 3
Используйте класс SettingsManager или что-то подобное, которое используется для абстрактного получения всех данных настроек. В каждой точке кода, где вам нужен параметр, вы запрашиваете класс SettingsManager - что-то вроде:
int timeout = SettingsManager.GetSetting("TimeoutSetting");
Затем вы делегируете всю логику того, как настройки выбираются для этого одного класса менеджера, реализация которого вы можете изменить/оптимизировать по мере необходимости. Например, вы можете реализовать SettingsManager для извлечения настроек из файла конфигурации или базы данных или какого-либо другого хранилища данных, периодически обновлять настройки, обрабатывать кеширование параметров, которые дорого извлекаются, и т.д. Код с использованием настроек остается блаженно не осознавая всех этих решений по внедрению.
Для максимальной гибкости вы можете использовать интерфейс вместо фактического класса, и у него есть разные администраторы настроек: вы можете менять их в нужное место в какой-то центральной точке, не изменяя базовый код вообще.
В .NET существует довольно богатый набор существующих классов конфигурации (в пространстве имен System.Configuration), которые предоставляют такие вещи, и это работает довольно хорошо.
Я не уверен в эквиваленте Java, но это хороший шаблон.
Ответ 4
Вот учебник по классу свойств. Из Javadocs (Properties):
Класс Properties представляет собой постоянный набор свойств. Свойства можно сохранить в потоке или загруженный из потока. Каждый ключ и его соответствующее значение в свойстве list - строка.
Список свойств может содержать другой список свойств как "умолчания"; это поиск второго списка свойств, если ключ свойства не найден в первоначальный список свойств.
В учебном пособии приведен пример создания экземпляра для типичного использования:
. . .
// create and load default properties
Properties defaultProps = new Properties();
FileInputStream in = new FileInputStream("defaultProperties");
defaultProps.load(in);
in.close();
// create application properties with default
Properties applicationProps = new Properties(defaultProps);
// now load properties from last invocation
in = new FileInputStream("appProperties");
applicationProps.load(in);
in.close();
. . .
Разумеется, вы могли бы также свернуть свою собственную систему прямо напрямую с помощью файлового хранилища и анализатора XML или YAML. Удачи!
Ответ 5
Недавно мы начали использовать инъекцию зависимостей JSR-330 (используя Guice из SVN) и обнаружили, что можно было прочитать в файле свойств (или любой другой карте) и связать его внутри Guice в модуле в стартовом коде, так что что
@Inject @Named("key") String value
Строка была введена значением, соответствующим ключу при вызове этого конкретного кода. Это самый элегантный способ, который я когда-либо видел для решения этой проблемы!
Вам не нужно перетаскивать объекты конфигурации вокруг вашего кода или посыпать всевозможные вызовы магических методов в каждом углу кода, чтобы получить значения - вы просто указали на Guice, в котором вы нуждаетесь, и он есть.
Примечание. Я посмотрел на Guice, Weld (Seam-based) и Spring, которые все обеспечивают инъекцию, потому что мы хотим, чтобы JSR-330 был в нашем собственном коде, и мне больше нравится Guice. Я думаю, причина в том, что Guice является самым ясным в своих привязках, в отличие от магии под капотом, происходящей с Weld.
