Я изучал способы сделать простую, устаревшую конфигурацию на основе файлов в Java. Я изучил встроенный в Java Properties
и библиотеку общей конфигурации Apache. Для последнего дистиллированный код выглядит следующим образом:
Configurations configs = new Configurations();
Configuration config = null;
try
{
config = configs.properties(new File("config.properties"));
}
catch (ConfigurationException cex)
{
}
long loadQPS = config.getInt("loadQPS");
Проблема, с которой я сталкиваюсь, заключается в том, что я вставляю это в каждый отдельный класс, что неоптимально по крайней мере по двум причинам: 1) Я читаю файл один раз для каждого класса, тогда как я должен прочитать его только один раз. 2) дублирование кода.
Одним из очевидных решений было бы создать класс конфигурации Singleton, к которому я затем получаю доступ из любого другого класса. Но, безусловно, это желательная функция почти в каждом случае использования, поэтому не следует ли ее включать в саму библиотеку конфигурации (я что-то упускаю)? Я также подумал об использовании конфигурации Spring, которая может создать для меня класс конфигурации Singleton, но не слишком ли много накладных расходов только для конфигурации на основе файлов? (Насколько я понимаю, сила весны в DI.)
Какое хорошее решение или передовой опыт (если он есть)?
РЕДАКТИРОВАТЬ: простое статическое решение, предложенное в ответе:
public class ConfigClass {
static Configuration config;
static {
Configurations configs = new Configurations();
Logger sysLogger = LoggerFactory.getLogger("sysLogger");
try
{
config = configs.properties(new File("config.properties"));
}
catch (ConfigurationException cex)
{
sysLogger.error("Config file read error");
}
}
}
Доступ в пакете по ConfigClass.config
.
Итак, у вас есть пара вариантов. Один из простых способов - сохранить объект конфигурации и получить к нему доступ статически.
Еще один способ, который мне нравится, когда я хочу внедрение зависимостей без Spring, - это структурировать программу удобным для DI способом. Вы можете эмулировать контейнер DI, преобразовав функцию main () в «конфигурацию» вашей программы, которая в конечном итоге ее запускает.
Рассмотрим типичное многоуровневое веб-приложение: дружественный к DI метод main () может выглядеть так:
public class AddressBookApp {
public static void main(String[] args) {
Configuration conf = new Configuration(args[0]);
// Creates our Repository, this might do some internal JDBC initialization
AddressBookRepository repo = new AddressBookRepository(conf);
// Pass the Repository to our Service object so that it can persist data
AddressBookService service = new AddressBookService(repo);
// Pass the Service to the web controller so it can invoke business logic
AddressBookController controller = new AddressBookController(conf, service);
// Now launch it!
new WebApp(new Controller[] { controller }).start();
}
}
Этот main () служит центральным местом для «подключения» вашего приложения, поэтому его легко передать каждому компоненту, который в нем нуждается.
Спасибо! Я решил пока использовать простое статическое поле - добавил свой код к вопросу выше.
Также отдельно отметим, что
Configuration config = null;
не выглядит очень элегантным. Предложения приветствуются!