Comments 9
В Spring-е и Java как всегда, придумали сотню невероятно сложных способов решить простейшую задачу - прочитать из файла настройки приложения.
Тонны аннотаций и конфигураций, фреймворков и библиотек, которые пересекаются между собой и работают каким-то магическим образом, или не работают.
И все это делает тоже самое что делает стандартный getProperty, без всяких фреймворков, аннотаций и конфигураций.
Properties prop = new Properties();
try(InputStream stream = new FileInputStream("application.properties")) {
prop.load(stream);
System.out.println(prop.getProperty("application.dog.name")
}
Вы правы, но это скорее философский вопрос подхода к разработке. Но, вообще-то, с @Value короче, чем у вас :)
Где же короче-то, наоборот длиннее, потому что переменная всегда создается, вот с@value
@Bean
class Config {
@Value("${application.dog.name}")
String dogName;
}
ApplicationContext context = SpringApplication.run(SpringPropertiesApplication.class, args);
System.out.println(context.getBean(Config.class).dogName);
+ 20 Мб зависимостей и медленная работа, т. к. там не умеют присваивать значения через =, там все через Reflection API
а у меня по-прежнему
Properties prop = new Properties();
try(InputStream stream = new FileInputStream("application.properties")) {
prop.load(stream);
System.out.println(prop.getProperty("application.dog.name")
}без дополнительных затрат
И вы по-прежнему просто прочитали строчку с диска. Вы не валидировали ее, вы не привели ее к нужному виду, вы не доставили ее до места применения, вы не научились ее обновлять на лету, вы ее даже не объединили в группу с другими свойствами того же вида. Вы просто прочитали строчку с диска, да еще завязавшись на конкретный файл свойств.
Ваш вариант просто загрузил свойство. Спринг со всеми его наворотами позволяет валидировать, возвращать дефолты, если свойство не найдено, и еще много чего, вплоть до измененя свойства в рантайме, при чем по сети. Эти "невероятно сложные" (нет) возможности стоят того, что бы их освоить, как мне кажется.
Я бы ещё сказал в пользу фреймворков вот что. Естественно, для того, чтобы прочитать свойство из конфига, подключать тонны зависимостей - это перебор. Но если фреймворк облегчает тучу действительно сложных и/или рутинных задач, то для решения таких задач использовать его имеет смысл. А если уж подключили, то почему бы не воспользоваться более мелкими удобствами, идущими в комплекте?
Ну и опять же, не всегда разработчик свободен в выборе инструментария. Рискну предположить, что поддержка занимает гораздо больше человеко-часов чем разработка новых продуктов. А по факту Spring сейчас де-факто индустриальный стандарт в бэкенде. Так что может нравиться, может нет, но очень многим дело с ним иметь приходится. Ну и, соответственно, возникает желание понимать "откуда что берётся"...
действительно сложных и/или рутинных задач
Какие такие там сложные задачи? Задачи-то на самом деле простые, только они невероятно сложно сделаны в spring-е, вот spring и объясняет мол мы решаем сложные задачи.
Вот, например, Hello, world HTTP сервер, из каждого первого spring-примера
HttpServer server = HttpServer.create(new InetSocketAddress(8000), 0);
server.createContext("/", e -> {
var response = "Hello, world".getBytes();
e.sendResponseHeaders(200, response.length);
e.getResponseBody().write(response);
e.close();
});
server.start();
на полностью стандартной Java, без фреймворков и зависимостей. Я бы не сказал что прям супер сложно.
Прекратите уже домонстрировать невежество, даже неловко становится. К тому же
@RestController
@RequestMapping("/api")
public class HelloWorldController {
@GetMapping("/get-hw")
String getHelloWorld(){
return "Hello world";
}
}по строчкам короче.
А почему вы демонстрируете свое превосходство над спрингом на таком примере? Может быть лучше сравнить ваш подход на реальном приложении? Там, где эксепшнхендлеры, логгинг, сбор метрик, трейсы и прочее? Ведь так и про spring-core можно сказать, что от его контекста и DI никакой пользы нет, и привести пример приложения с 5 классами...
Ещё раз о пропертях или откуда что берётся