Большинство моих профессиональных Java проектов за последнее десятилетие были основаны на Sring или JEE. Обе платформы развиваются достаточно уверенно, однако все ещё страдают от различных проблем.
JEE изменилась довольно резко на протяжении многих лет, но до сих пор осуждается разработчиками за подходы и решения, которые были обозначены создателями платформы как deprecated ещё начиная с версии EJB 2.x. Многие люди до сих пор называют JEE как “J2EE”, хотя изменение названия состоялось 8 лет назад!
Spring тоже заметно усовершенствовался, однако далеко не всеми пользователями это воспринимается. Невзирая на возможность создания при помощи Spring 3.x и выше современных приложений с прозрачной, неоторванной от кода конфигурацией, большинство проектов продолжают с избытком пестреть XML-файлами и устаревшими архитектурными решениями. Проблема в том, что много разработчиков по тем или иным причинам не меняют отработанного на предыдущих версиях подхода.
Spring и JEE по-прежнему остаются золотыми стандартами для масштабных Java-проектов и больших команд разработчиков, трудящихся над сложными enterprise-решениями. Однако, неизбежным следствием зрелости Java-сообщества сала частичная потеря прежнего энтузиазма и инновационности, что существенно ударило и по авторитету Spring.
По указанным причинам открылась дорога другим языкам и фреймворкам. Java был, вероятно, самым популярным языком для личных проектов, более десятка лет тому назад, но молодые разработчики сегодня, кажется, стали обращать больше внимания на Python, Scala и т.д. Наиболее влиятельные веб-фреймворки предыдущего десятилетия Rails, и основанная на Ruby Sinatra породили ряд микро-фреймворков на протяжении последних пяти лет.
Groovy и Grails, в мире Java, стали первым серьёзным ответом Ruby и Rails. Их теперь можно встретить в наборе инструментов даже самых консервативных команд enterprise-разработки. Однако, новые фреймворки на основе JVM идут гораздо дальше. Вместо просто обёртывания API JEE и Spring в легкую для использования интерфейс-оболочку Play фреймворк начал, так сказать с чистого листа, отбрасывая даже, казалось бы фундаментальную модель Java-сервлета.
Spring уже не рассматривается как современный инновационный инструмент. Разработчики еще используют его, особенно для старых приложений, но в основном, потому что они должны, а не потому, что они этого сами хотят. Я не могу вспомнить, когда последний раз я говорил с разработчиком, использовавшем Spring в личном проекте, в то время как Play или совершенно другая платформа встречаются повсеместно.
Это позор, ведь Spring – невероятно мощный инструмент, если получится правильно его настроить. Spring Data JPA предоставляет простое управление реляционными базами данных без написания классов DAO, также Spring Data JPA позволяет получить тот же функционал по отношению к NoSQL хранилищам данных, если получится правильно его настроить. Кроме того, с помощью Spring вы имеете возможность осуществлять enterprise-интеграцию, доступ к API самых популярных социальных сервисов для ваших веб- или android-приложений, позаботится о безопасности вашего приложения посредством Spring Security, но, опять же, если у вас получится правильно все сконфигурировать.
Построение приложения на основе Spring может быть очень болезненным процессом. Отчасти это из-за большого количества существующих альтернатив при выборе технологий. Например, стоит ли осваивать и использовать Spring Data JPA, если вы уже потратили время на изучение JdbcTemplate и Hibernate/JPA? Какая разница между Spring Data REST и Spring HATEOAS?
Другим осложняющим фактором является то, что Spring редко признает что-либо deprecated, и не предоставляет достаточной информации для принятия обоснованного решения по выбору технологий, устранения разнообразных конфликтов и решения других часто возникающих проблем. Если вы будете искать в Интернете пример устранения какой-то неполадки, ссылки на устаревшие подходы и решения будут в топе результатов поиска. По большей части именно из-за этого XML-конфигурация остается такой распространённой, невзирая на простоту имплементации и поддержки конфигурации на основе аннотаций. Вместо использования чистой системы шаблонов такой как Thymeleaf или Velocity, в большинстве приложений по-прежнему применяется JSP с JSTL.
Жажда к ликвидации указанных проблем никогда не угасала у создателей Spring. Вдохновившись инструментом командной строки Rails, они презентовали Spring Roo – систему быстрой разработки, которая кроме того позволяет создавать элементы, такие как веб-контроллеры или JPA сущности посредством командной строки. Тем не менее, для нетривиального использования, освоить Spring Roo почти так же сложно, как собирать приложения вручную. Многих разработчиков отталкивало обилие аннотаций и AspectJ-файлов, которые Roo повсеместно добавляет в проект для обеспечения своей “магии”. Хотя и заявляется, что Roo можно легко и безболезненно удалить из проекта, если понадобится, реальность оказывается более суровой, чем теория. И даже если у вас все получилось, конвертация AspectJ в Java напрочь лишает вас возможности пользоваться магическим инструментом командной строки.
Spring Boot – следующая генерация средств упрощения процесса конфигурации Spring приложений. Он не является средством автоматической генерации кода, а представляет собой плагин для системы автоматизации сборки проектов (поддерживает Maven и Gradle).
Плагин предоставляет возможности для тестирования и разворачивания Spring приложения. Команда mvn spring-boot:run обеспечивает запуск вашего приложения на порту 8080. Это чем-то напоминает довольно популярный плагин Maven Jetty. Кроме того, Spring Boot позволяет упаковывать приложение в отдельный jar-файл, с внедренным полноценным контейнером Tomcat. Этот подход позаимствован у модели развертывания приложений фреймворка Play (вместе с тем вы также можете создавать традиционные war-файлы).
Основная выгода Spring Boot – конфигурирование ресурсов исходя из содержания classpath. Например, если pom.xml файл вашего Maven проекта содержит JPA зависимости и драйвер PostgreSQL, Spring Boot настроит persistence-модуль для PostgreSQL. Если вы добавили веб-зависимость, вы получите сконфигурированный по умолчанию Spring MVC. Если вам нужна персистентность и ничего кроме этого, Spring Boot сконфигурирует Hibernate как JPA провайдер с базой данных HSQLDB. Если вы создаете веб-приложение, но не указываете ничего дополнительно, Spring Boot сконфигурирует view resolver для системы шаблонов Thymeleaf.
Говоря о конфигурации по умолчанию, Spring Boot достаточно интуитивен в этом плане. Вы можете не всегда быть согласны с его выбором настроек, но, по крайней мере, он предоставит вам работающий модуль. Это очень полезный подход, особенно для начинающих разработчиков, которые могут начать работу с настройками по умолчанию, а потом, по мере изучения существующих альтернатив, вносить изменения в конфигурацию. Согласитесь, это намного лучше чем получить кучу сложных вопросов, без решения которых просто невозможно стартовать. Вдобавок на официальной странице проекта projects.spring.io/spring-boot/ есть ряд полноценных туториалов, позволяющих быстро понять и практически реализовать все основные виды проектов на уровне “Hello world”.
Построение инфраструктуры приложения, фактически заключается в добавлении нужных модулей в pom.xml:
...
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.0.0.RC3</version>
</parent>
...
<properties>
<start-class>com.mypackage.Application</start-class>
<java.version>1.7</java.version>
</properties>
...
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<version>1.3.174</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
...
а также написании main Java-класс следующим образом:
@Configuration
@EnableAutoConfiguration
@ComponentScan
@PropertySource("classpath:application.properties")
public class Application {
@Bean
MyCustomService myCustomService() {
return new MyCustomService("");
}
public static void main(String[] args) {
ApplicationContext ctx = SpringApplication.run(Application.class, args);
System.out.println("Let's inspect the beans provided by Spring Boot:");
String[] beanNames = ctx.getBeanDefinitionNames();
Arrays.sort(beanNames);
for (String beanName : beanNames) {
System.out.println(beanName);
}
}
}
Для большинства случаев изменения настроек по умолчанию, достаточно изменить POM-файл. Так, в примере выше продемонстрированно добавление зависимости для базы данных H2. Spring Boot, видя такое изменение, конфигурирует persistence-модуль JPA для базы данных Н2 вместо, предлагаемой по умолчанию HSQLDB. Если вам хочется использовать Jetty как встроенный контейнер, вместо предлагаемого по умолчанию Tomcat, просто добавьте соответствующую зависимость.
В данный момент Spring Boot находится на этапе становления, и, безусловно, до выхода на стабильный уровень ему предстоит пережить немало метаморфоз. Возможно, его еще рано использовать для построения серьезных систем, однако он вполне подходит для выполнения разного рода персональных, тренировочных и тестовых проектов, при реализации которых очень важно избавится от нежелательного объема непродуктивной, рутинной работы, никоим образом не связанной с созданием полезной функциональности.
В контексте потенциальных перспектив перерастания Spring Boot в будущем в серьезный инструмент для Spring разработки, особенно обнадёживает присутствие приемлемой технической документации (правда, только на английском языке и все ещё достаточно скудной, в сравнении с 800 страничной “энциклопедией” Spring Framework).
Автор: alexVengrovsk
