spring с чего начать

Изучение Spring Framework 100% через практику. Активные туториалы и язык разметки KML. Проект KciTasks (beta)

Spring Framework традиционно считается одним из самых сложных и при этом высокооплачиваемых. Однако, существующие подходы к его изучению крайне неэффективны. Я хотел бы предложить вам принципиально новый подход к изучению спринга, который заключается в использовании концепции активных туториалов. Они представляют из себя сбалансированный набор инструкций, которые поддерживают внимание разработчика и проводят его через те или иные аспекты фреймворка.

В результате, мы получаем целенаправленное обучение, но БЕЗ ступоров, проблем непонимания вида «а где это использовать», а также без скучного и пассивного чтения теории. Совсем.

В рамках статьи представлено 5 учебных задачек, которые покрывают Spring Jdbc/Transactions на 50% от необходимых для сертификации знаний. Главная задача статьи — массово протестировать саму идею, а также вместе с вами разработать большое количество уникальных задачек по всем темам.

Для начала немного о себе. Меня зовут Ярослав, и я работаю на позиции Middle Java Developer в компании EPAM Systems. Одним из моих хобби является создание обучающих систем (диплом бакалавра, диплом магистра). За последние 4 года я перепробовал более сотни самых разнообразных подходов к обучению различных областей знаний (включая Java/Spring), и создал более двадцати программ-прототипов для проверки этих подходов. Большинство из них не принесло какой-либо супер-пользы, и поэтому я продолжаю работу в этом направлении.

Эта статья посвящена одной из моих идей, которая, теоретически, может взлететь. Надо её массово протестировать, в этом и заключается задача данной статьи. Забегая вперёд, рекомендую вам зайти и посмотреть веб-страницу с задачками, чтобы понимать, о чём идёт речь (https://kciray8.github.io/KciTasks/App/src/).

Я перфекционист и хочу, чтобы обучение было близким к идеальному. В моём понимании это такое обучение, которое не вызывает негативных эмоций, затягивает и приносит удовольствие. К сожалению, изучение многих современных (и высокооплачиваемых) технологий вызывает трудности. Spring Framework традиционно считается одним из самых сложных в изучении, и его изучение происходит крайне неэффективно.

Как обычно изучают Spring

В изучении фреймворков есть 2 крайности. Первая — когда человек работает в компании и просто делает те задачи, которые даёт заказчик. Это медленный, очень медленный способ развития, но по нему идут большинство разработчиков. Логично делать только то, что просят, особенно когда за это платят, не так ли? Однако, обучение «на работе» лишь кажется эффективным. Большинство задач, которые решают современные программисты, заключается в сопровождении систем. Всё уже написано до нас, нужно лишь фиксить баги\править конфиги, и дорабатывать систему напильником. В этом нет ничего плохого, но вот обучение самим технологиям происходит крайне медленно. Конечно, рано или поздно вам придётся раскопать документацию спринга и вы запомните всё необходимое, но на это уйдут годы. Может быть, стоит попробовать сначала «накрутить» знания и опыт, а потом уже брать практические задачки посложнее (и за существенно больший оклад, разумеется)? (С Java это точно работает, можно за 2-3 месяца целенаправленно изучить Java SE и это могут засчитывать за год-другой опыта. Много знакомых с универа, кто так делал).

Вторая крайность — это целенаправленное обучение. Это быстрый, но ОЧЕНЬ тяжёлый способ. Он заключается в том, что человек продвигается по книге (или курсу), а потом пытается применить это на практике и как-то запомнить. И если с Java SE такой подход ещё кое-как работает, то со спрингом всё глухо и туго. Даже в самых лучших книгах зачастую не объясняется, где конкретно применять те или иные особенности, приходится догонять это самому. Но самое обидное тут — это забывание информации, добытой таким тяжёлым трудом. Одна из проблем обучения — это отсутствие эффективного повторения. Если вы изучали спринг классическим способом (например, читали книгу и пробовали код на практике), то на это были потрачены огромные усилия, но БЕЗ возможности восстановления. Простое перечитывание книги через 1-2 года не вернёт вам забытой информации (которую вы получили через практику, параллельную с прочтением). Возникает некая дилемма — как же сделать так, чтобы было много практики, но при этом программист «направлялся» в нужные области?

Проблемы обучения

Итак, мы пришли к выводу, что крайности в обучении — это плохо. Давайте подумаем, как можно оптимизировать процесс. Целенаправленное обучение выглядит правильной идеей, которую нужно развивать дальше. Рассмотрим более подробно, почему же это вызывает трудности у большинства людей.

Для начала, выберем материалы, по которым стоит обучаться. Главное требование к ним — ограниченный набор информации (только то, что нужно для сертификации/собеседования/практики), а также последовательная и логически взаимосвязанная подача этой информации. По данным критериям, наилучшим образом подходят книги (Спринг в действии, Учебное пособие по сертификации от Юлианы и т.д.) Они очень хорошо продуманы и оформлены (на мой взгляд, куда приятнее и подробнее, чем видеокурсы по спрингу на udemy). Казалось бы, читай себе, вникай, пробуй, экспериментируй — и будут знания! Но не тут-то было.

Дело в том, что сам процесс чтения книги и разбора теории в ней очень плохо состыкован с процессом апробации этой теории на практике. Он не естественный. Какой бы ни была книга идеальной, она остаётся книгой. Она по своей природе не предназначена для обучения программированию. Программист, в конечном итоге, должен набивать хорошие привычки по сознательному использованию тех или иных технологий фреймворка. Между «Я прочитал и понял» и «Я умею это применять и знаю где» образуется огромная пропасть. Чтобы преодолеть её, приходится вложить немалые усилия. Скажу честно — я написал довольно много веб-приложений на Spring, однако всё равно испытывал множество трудностей при прочтении глав книги «Спринг в действии». На данный момент я детально разобрал около 30% из обеих книг, и готов к сертификации Spring 5 примерно на 60%.

Аналогичные проблемы я наблюдал при изучении Android SDK в 2014 году. Разгадка тут довольно простая — каждый фреймворк вводит какие-то свои новые концепции, которые довольно трудно понять и начать думать через них (если использовать традиционные способы обучения).

Процесс связывания представленной в книге информации с привычками — очень тяжёлый и не эффективный. Он часто вызывает множество негативных эмоций (когда что-то не работает или не запускается), заставляет много гуглить и решать проблемы. Неужели нельзя сделать некоторые «пути (trails)», по которым можно будет провести разработчика, показать ему правильные решения, да так, чтобы он сам их делал? Ведь опытные разработчики прекрасно знают о таких путях. Для них это что-то очевидное. Но тут возникает проблема в форме передачи знаний. Как мы уже выяснили, книги не подходят для этой цели.

Ещё одна проблема, на которую хотелось бы обратить внимание — это проблема повторения. Даже если мы преодолеем все трудности и широко прокачаем знания спринга, со временем они будут угасать (не считая того небольшого процента, который получилось связать с текущими задачами). Человеку свойственно забывать, и с этим ничего не поделать. Единственное, что мы можем сделать — это попробовать оптимизировать повторения. Когда я учился в бакалавриате, я возлагал большие надежды на теорию интервального повторения и хранение знаний в виде флеш-карт (Хабростатья про диплом бакалавра). Однако, флеш-карты слишком независимы друг от друга (не подходят для хранения связанных знаний о спринге). Даже для изучения Java их эффективность средняя. Да и они тоже не естественны, ведь программист должен повторять через практику.

Я многие годы ломал голову над тем, как сделать обучение 100% завязанным на практику (как следствие — не скучное и с высоким КПД). Сейчас я коротко расскажу о вариантах, которые были перепробованы. Для начала, я пытался найти набор подробных и учебных ТЗ, которые бы, кроме задач давали бы технические наводки (разработать такой-то REST Api используя такие-то классы). Ничего дельного я не нашёл, и потратил кучу времени. Да, я видел отдельные авторские курсы по некоторым частям спринга, но полного покрытия сертификации нигде не собрать. Да и «книжная» проблема этих туториалов остаётся (хоть и некоторые авторы пытались сделать пошаговые руководства, они всё равно имеют недостатки). P.S.: Если у вас есть что-то вроде «Учебных ТЗ» по спрингу, обязательно отправьте их мне на kciray8@gmail.com.

Одна из проблем книг и туториалов — их очень скучно и нудно читать. Это ещё больнее, чем гуглить баги. Я не хочу читать, я хочу кодить! Что, если использовать книгу только для наводки на темы и названия классов, а потом уже самостоятельно (через эксперименты и гугл) догонять всё остальное? А уже потом и главу перечитывать, пересиливая себя и собирая оставшиеся крупицы знаний. Собственно, я так и изучал спринг. Не с начала главы (унылое введение), а с середины, пытаясь за что-то ухватиться и экспериментировать вокруг этого. IDE очень помогает в этом с помощью автозаполнения, просмотра JavaDoc и исходников, удобной отладки. Я бы назвал это «изучение с помощью экспериментов с API». Я даже развил ряд особых методик вокруг этого метода, но там всё равно остаются некоторые фундаментальные проблемы.

А именно, проблема «ступоров» никуда не девается. Она вызывает по-прежнему много боли, хоть это уже более естественно и приближенно к практике (в реальных проектах придётся много таких ступоров решать, прокачать навык будет полезно). На самом деле, на этой методике можно вполне себе дойти до конечной цели (сертификация). Но это будет требовать очень много усилий, в 3-4 раза больших, чем если бы идти по накатанной дорожке. Да и проблема повторения информации всё равно остаётся. И хочется сделать что-то более приближенное к идеальному. Вдруг моя новая методика окажется полезным большому количеству людей и изменит мир? И в конце 2017 года мне пришла в голову такая идея, да так, что захотелось её сразу реализовать и изначально я делал очень большие ставки на успех.

Давайте подумаем, как происходит обучение по классическому (большей частью пассивному) туториалу. Большинство туториалов по Spring просто отвратительны по своей структуре (включая гайды на spring.io). Самый большой их недостаток, который я просто терпеть не могу — это линейность. Многие авторы «вываливают» большие куски кода, которые нужно копипастить к себе. Было бы правильнее начинать с простого примера (минимально возможной демонстрации, которую можно запустить и поэкспериментировать), и потом накручивать на него разные навороты. Принцип «от простого к сложному» — золотой закон обучения! Но нет ведь. Каждый автор считает нужным накрутить информации в 2-4 раза больше чем нужно, по кускам это разбирать и только потом запускать.

К примеру, откроем руководство по поднятию SOAP-сервиса на спринге (https://spring.io/guides/gs/producing-web-service, недавно на работе понадобилось). Они тут и spring-boot прикрутили, и wsdl4j с процессом генерации Java-классов с использованием gradle, и целый in-memory репозиторий CountryRepository (хотя простой строки «Hello world» мне хватило бы). И только в самом конце объяснили, как с помощью curl запустить всю эту систему. Нет, я конечно всё понимаю — авторы хотели дать наглядный пример «всё в одном» и разобрать его. Но, с точки зрения понимания информации, такой подход не годится.

Вы любите «читать» скучный разбор и копипастить куски кода (каждый по пол страницы)? Я это терпеть не могу. Хочу вот получать опыт экспериментальным путём, и всё тут.

Идея активных туториалов (KciTasks)

Что, если сделать некое подобие виртуального учителя, который просто даёт маленькие указания типа «сделай то и это», а в случае, если программист ошибся или забыл — учитель просто даёт фрагмент кода. По своей сути, кси-таски и являются таковыми. Суть их в том, что у нас есть маленький набор инструкций, к каждой из которых есть ответ и он под спойлером (скрыт). Разницу между ними и обычным туториалом можно увидеть на следующем графике:

Концепция проекта с чистого листа

Перед тем, как продолжить разбор активных туториалов, хотелось бы рассказать об одной важной концепции, на которой они базируются. Эту концепцию вы можете использовать совместно с любой методикой обучения, но почему-то о ней редко пишут или упоминают где-то. Так вот, суть её в том, что тренировочные проекты нужно делать с нуля. Никаких start.spring.io, каждый день заходите в File->new Project->Hello world и на нём базируете ВСЕ ваши проекты, включая веб. И все maven-зависимости тоже забиваете по-новому. Благодаря этому вы запомните зависимости между спринг-модулями, зачем нужен каждый из них и т.д. На практике это очень сильно пригождается, когда есть какие-то проблемы с зависимостями.

Практическая направленность

Любите ли вы XML? Авторы обеих книг по Spring соглашаются, что рано или поздно XML станет пережитком прошлого. Однако, они сами приводят большинство решений в двух вариантах (XML+Аннотации). Я не любил XML до тех пор, пока не устроился в большую компанию. Сейчас это просто часть работы. Слишком много готовых решений сделано, которые просто пронизаны XML и переписать их без него — потратить огромные деньги и получить несравнимо мало. Никто не будет этого делать. Поэтому, я старался чередовать XML/Аннотации в моих задачках, что и вам рекомендую. Если правильно обучаться (по описанной в статье методике), то XML не вызывает проблем, а, напротив, помогает взглянуть с другой стороны на некоторые решения и лучше их запомнить. Написание XML кода (с автозаполнениями и подсказками, с помощью IDE) также приятно, как и написание Java кода.

Приближаемся к идеалу (0.5% копипасты, 5% чтения)

Каждая инструкция в активном туториале должна быть выполнимой БЕЗ копипасты. Современные IDE позволяют умножить её на ноль. Да, даже beans.xml со всеми его приблудами, даже dependencies — всё можно сделать внутри IDE. Это намного приятнее, чем бездумно копировать код. Как я уже сказал, я хочу сделать обучение приятным и это одно из проявлений.

Каждая инструкция в кси-таске заставляет вас немножко подумать и что-то вспомнить. В этом и заключается «активность» такого туториала. Этот процесс намного приятнее, чем чтение или копирование кода. Тут нужно поддерживать баланс — инструкция не должна быть слишком тупой (иначе это будет не так приятно), и не должна быть слишком сложной (что повлечет за собой большие куски кода и проблемы, аналогичные с туториалами). Я нигде не видел подобных разработок, хоть и повидал много разных систем обучения.

Специальный язык для активных туториалов (KML)

Одна из причин, по которым активные туториалы до сих пор никто не распространил — отсутствие формата для их хранения. Существующие языки разметки совершенно не подходят для перемешивания кода и текста. Первую версию KciTasks я сделал как надстройку на HTML, и это было просто ужас как неудобно! Потом я сделал свой небольшой язык разметки, который отличным образом подходит для тасок и компилируется в HTML. И происходит это прямо во время загрузки веб-страницы. Вот примеры:

Пример 1 — Создание бина JdbcTemplate

Пример 2 — Создание файла schema.sql

План полного покрытия Core Spring 5.0 Certification

В интернете существует холивар о том, нужны ли сертификаты. Об этом можно написать отдельную статью, но в рамках этой статьи я просто напишу «нужны и как можно больше». Месяц назад вышел Study Guide по Spring 5 (и сам экзамен от pivotal), поэтому имеет смысл ориентироваться на него. Для нас это может служить в качестве плана, или некоторого стандартного набора, который спрашивают на собеседованиях и который может быть полезен для ваших проектов.

По каждой теме нужно сделать 6-8 уникальных задачек, которые затрагивают требуемый объём знаний и подают информацию с разных точек зрения (например, DataSource создаётся разными способами — с помощью билдеров, вручную, с использованием пропертей, через аннотации или XML, автоматически через Boot и т.д.). Потренировавшись, программист надёжно запомнит, что же такое DataSource и как он применяется (вместо того, чтобы «выучить, сдать и забыть», как делают многие). Кроме того, темы часто взаимно пересекаются (Container и AOP используются в Spring Data). Это позволяет очень хорошо углубить основы основ.

Не смотря на максимальную автоматизацию процесса через язык разметки, разработка тасок остаётся весьма трудоёмкой задачей. Особенно, если их делать качественно (демонстрируя всё в простой форме и с правильной перспективы). Например, мне потребовалось около 10 часов, чтобы разработать задачку по уровням изоляции в транзакциях. Казалось бы, нужно всего лишь продемонстрировать разницу между 4-мя уровнями, запустив транзакции параллельно. Но не тут-то было! Для H2 и MySQL не видна разница между некоторыми уровнями, и они по-разному обрабатывают конфликтные ситуации (одни БД возвращают старые копии данных, другие — вводят транзацию в режим ожидания). И только в DerbyDB наглядно можно увидеть разницу между всеми уровнями. Все авторы книг такие умные — копируют теорию, а вот показать её на практике — полноценный пример так и не получилось найти, пришлось самому выводить.

Суть моего плана в том, чтобы объединить мои усилия с вашими и вместе разработать большое количество уникальных задачек по Spring 5. Все, что требуется от вас, это отправить мне на почту *.kml-файлик с задачкой, и zip-архив проекта. Задачки будут доступны бесплатно и без регистрации, для всех, через GitHub-вебсайт. Или вы можете сделать пулл-реквест (если нужно что-то доработать в самом движке). Я верю, что вместе мы сможем создать новый принцип обучения и нести его в массы.

Также, хочу обратить внимание на просьбу поддержать проект в виде доната (в шапке сайта баннер). Очень хотелось бы получить компенсацию по затраченным усилиям (а сообщество Java-разработчиков далеко не бедное).

Рекомендации

По каждой теме спринга можно придумать множество уникальных тасок. Например, вы можете давать указания по разработке некоторого REST API через спринг MVC, а потом получать данные с него через RestTemplate и выводить их в консоль. Получается 2 в 1, некоторое замкнутое кольцо. Вообще, простор для творчества тут очень большой, нужно лишь время и желание. И чем больше уникальных задачек, тем лучше! Если вы хотите добавить что-то своё (необычное) — вперёд. Многогранность обучения очень важна. Нужно показать одни и те же знания с большого количества разных ракурсов, тогда они хорошо запомнятся. Главное — соблюдайте баланс, о котором говорилось выше (каждая инструкция требует что-то сделать, но не слишком много). Вместе мы сможем конвертировать знания из книг в форму тасок и сделать большое дело!

P.S.: Если кто-то из читателей проходил экзамен и/или официальный курс от pivotal, напишите мне на kciray8@gmail.com.

Система обучения или система повторения?

Я вижу два пути, по которым вы можете использовать KciTasks. Первый — использовать её для углублённого изучения спринга. На мой взгляд, это должно быть эффективно. Вы просто выполняете инструкцию за инструкцией, сверяясь с решением и корректируя себя. По началу вы будете много «подглядывать» туда, но это нормально. На следующий день попробуйте подглядывать как можно меньше и всё делать самому. Все таски рассчитаны на то, чтобы быть сделанными без разворачивания спойлеров, СОВСЕМ. Вам надо к этому прийти. Обратите внимание, что вы не гуглите (. ), не читаете доки или книжку. Таски самодостаточны, просто вчитвайтесь в инструкцию и решение к ней, и выводите знания из экспериментов.

Второй путь — использовать KciTasks для повторения. Когда вы изучаете какой-либо фрейм или язык программирования по книге/курсу, вы вкладываете много усилий. И пусть они не пропадут даром — вложите весь полученный опыт в таски, чтобы потом через полгода можно было пройти по проторенной дорожке и всё вспомнить.

Оба путя не протестированы (beta же), поэтому жду ваших отзывов. И чем подробнее, тем лучше. Ведь все люди разные, восприятие разное, и надо посмотреть реакцию сообщества. Надеюсь, что статья окажется полезной.

Источник

Как писать на Spring в 2017

В одной из классических статей для новичков, мелькавших недавно на Хабре, рассказывалось про создание базового Web приложения на Java. Все начиналось с сервлета, потом создания JSP страницы и, наконец, деплоймента в контейнер. Посмотрев на это свежим взглядом я понял, что для как раз для новичков это, наверняка, выглядит совершенно жутко — на фоне простых и понятных PHP или Node.js, где все просто — написал контроллер, вернул объект, он стал JSON или HTML. Чтобы немного развеять это ощущение, я решил написать «Гайд для новичков в Spring». Цель это статьи — показать, что создание Web приложений на Java, более того — на Spring Framework это не боль и мучительное продирание через web.xml, persistence.xml, beans.xml, и собирание приложения как карточного домика по кусочкам, а вполне себе быстрый и комфортный процесс. Аудитория — начинающие разработчики, разработчики на других языках, ну и те, кто видел Спринг в его не самые лучше времена.

Введение

В этой статье мы посмотрим, что включает в себя современный Спринг, как настроить локальное окружение для разработки Веб приложений, и создадим простое веб-приложение, которое берет данные из БД и отдает HTML страницу и JSON. Как ни странно, большинство статей (на русском языке) для начинающих, которые я нашел в топе поиска описывают и ручное создание контекста, и запуск приложения, и конфигурацию через XML — ничего из этого в современном Спринге делать, разумеется, не обязательно.

Что такое Spring?

Для начала пара слов, что же такое Spring. В настоящее время, под термином «Spring» часто подразумевают целое семейство проектов. В большинстве своем, они развиваются и курируются компанией Pivotal и силами сообщества. Ключевые (но не все) проекты семейства Spring это:

Spring Framework (или Spring Core)
Ядро платформы, предоставляет базовые средства для создания приложений — управление компонентами (бинами, beans), внедрение зависимостей, MVC фреймворк, транзакции, базовый доступ к БД. В основном это низкоуровневые компоненты и абстракции. По сути, неявно используется всеми другими компонентами.

Spring MVC (часть Spring Framework)
Стоит упомянуть отдельно, т.к. мы будем вести речь в основном о веб-приложениях. Оперирует понятиями контроллеров, маппингов запросов, различными HTTP абстракциями и т.п. Со Spring MVC интегрированы нормальные шаблонные движки, типа Thymeleaf, Freemaker, Mustache, плюс есть сторонние интеграции с кучей других. Так что никакого ужаса типа JSP или JSF писать не нужно.

Spring Data
Доступ к данным: реляционные и нереляционные БД, KV хранилища и т.п.

Spring Cloud
Много полезного для микросервисной архитектуры — service discovery, трасировка и диагностика, балансировщики запросов, circuit breaker-ы, роутеры и т.п.

Spring Security
Авторизация и аутентификация, доступ к данным, методам и т.п. OAuth, LDAP, и куча разных провайдеров.

Типичное веб приложение скорее всего будет включать набор вроде Spring MVC, Data, Security. Ниже мы увидим, как это все работает вместе.

Особняком стоит отметить Spring Boot — это вишенка на торте (а некоторые думают, что собственно сам торт), которые позволяет избежать всего ужаса XML конфигурации. Boot позволяет быстро создать и сконфигурить (т.е. настроить зависимости между компонентами) приложение, упаковать его в исполняемый самодостаточный артефакт. Это то связующее звено, которое объединяет вместе набор компонентов в готовое приложение. Пару вещей, которые нужно знать про Spring Boot:

Настройка окружения

Для того, чтобы создать простое приложение, знать, как создать проект Maven с нуля, как настроить плагины, чтобы создать JAR, какие бывают лейауты в JAR, как настроить Surefire для запуска тестов, как установить и запустить локально Tomcat, а уж тем более, как работает DispatcherServlet — совершенно не нужно.

Современное приложение на Spring создается в два шага:

Spring Initializr позволяет «набрать» в свое приложение нужных компонентов, которые потом Spring Boot (он автоматически включен во все проекты, созданные на Initializr) соберет воедино.

В качестве среды разработки подойдет что угодно, например бесплатная IntelliJ IDEA CE прекрасно справляется — просто импортируйте созданный pom.xml (Maven) или build.gradle (Gradle) файл в IDE.

Стоит отдельно отметить компонент Spring Boot который называется DevTools. Он решает проблему цикла локальной разработки, который раньше выглядел как:

В те древние времена даже родилась поговорка, что Spring это DSL для конвертации XML конфигов в стектрейсы.

С включенными Spring Boot DevTools цикл разработки сокращается до:

DevTools будут автоматом проверять изменения в скомпилированном коде или шаблонах, и очень быстро перезапускать (hot reload) только «боевую» часть приложения (как nodemon, если вы знакомы с миром node.js). Более того, DevTools включают интеграцию с Live Reload и после установки расширения в браузере, достаточно скомпилировать проект в IDEA, чтобы он автоматом обновился в браузере.

Разработка

Окей, пора приступать к практической части. Итак, наша цель — создать веб-приложение, которое отдает welcome страницу, обращается с нее же к собственному API, получает JSON с данными из базы и выводит их в таблицу.

Новый проект

Точнее, контейнер нужен — только он предоставлен и настроен Spring Boot-ом — используя Embedded Tomcat

Контроллер

Итак, наш следующий шаг — создать контроллер и вернуть «домашнюю» страницу. Код контроллера выглядит так просто, как и ожидается:

Пара вещей, на которые стоит обратить внимание.

С Котлин это бы выглядело еще лучше и проще, но это потребует введения сразу большого количества новых понятий — язык, фреймворк. Лучше начинать с малого.

Класс, помеченный как @Controller автоматически регистрируется в MVC роутере, а используя аннотации @(Get|Post|Put|Patch)Mapping можно регистрировать разные пути.

Все файлы из каталога resources/static/ считаются статическими, там можно хранить CSS и картинки.

Шаблон

Мы используем Mustache (Handlebar) синтаксис, поэтому шаблон очень напоминает обычный HTML

После компиляции проекта (⌘/Ctrl + F9) — можно сразу идти на http://localhost:8080 и увидеть созданную страницу.

Доступ к базе

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

Предвидя череду комментариев «Как же без геттеров и сеттеров» и «Где же equals / hashCode» — эти элементы упущены сознательно с целью упрощения кода. Совершенно чудовищная ошибка дизайна Java которая заставляет писать эту ерунду (геттеры и методы сравнения), это, конечно, отдельный разговор. Котлин эту проблему, кстати, решает.

Мы снова очень активно используем аннотации — в этот раз из Spring Data (точнее, JPA — это дремучая спецификация для доступа к данным). Этот класс описывает модель с двумя полями, одно из которых генерится автоматически. По этому классу будет автоматически создана модель данных (таблицы) в БД.

Теперь для этой модели пора создать репозиторий. Это еще проще, чем контроллер.

Все, репозиторий можно использовать для работы с базой — читать и писать записи. У внимательного читателя должен сработать WTF детектор — что здесь вообще происходит? Мы определяем интерфейс и внезапно он начинает работать с базой? Все так. Благодаря магии Spring Boot и Spring Data «под капотом» происходит следующее:

Чтобы использовать репозиторий в контроллере мы воспользуемся механизмом внедрения зависимостей, предоставляемый Spring Framework. Чтобы это сделать, как ни странно, нужно всего лишь объявить зависимость в нашем контроллере.

Теперь можно писать в базу в методе контроллера.

REST контроллер

Следующий шаг — это вернуть все записи из базы в JSON формате, чтобы потом их можно было читать на клиенте.

На что обратить внимание:

Теперь при запросе http://localhost:8080/api/visits (предварительно скомпилировав проект и дав DevTools обновить приложение) мы получим JSON с нужными данными.

Клиентский код

Оставим за рамками этой статьи, пример можно увидеть в исходном коде. Цель этого кода — исключительно продемонстрировать как получить JSON данные с сервера, интеграции с клиентскими фреймворками React, Angular etc намеренно оставлены вне рамок этой статьи.

Тестирование

Spring так же предоставляет мощные средства для Integration и Unit тестирования приложения. Пример кода, который проверяет контроллер:

Используя абстракции типа MockMvc можно легко тестировать внешний интерфейс приложения, в то же время имея доступ к его внутренностям. Например, можно целиком заменить компоненты приложения на моки (заглушки).

Аналогично для API тестов есть набор хелперов для проверки JsonPath выражений.

Тестирование в Spring это все таки отдельная тема, поэтому мы не будем сильно на этом останавливаться сейчас.

Деплоймент

Чтобы собрать и запустить наше приложение в продакшене есть несколько вариантов.

Таким образом сборка и запуск приложения выглядит как:

Для деплоймента этого JAR файла не нужно ничего, кроме установленной Java (JRE). Это так называемый fat JAR — он включает в себя и встроенный сервлет контейнер (Tomcat по умолчанию) и фреймворк, и все библиотеки-зависимости. По сути, он является единственным артефактом деплоймтента — его можно просто копировать на целевой сервер и запускать там.

Более того, файл можно сделать «выполняемым» и запускать его просто из командной строки (Java, конечно, все равно необходима).

На базе этого файла можно легко создать Docker образ или установить его как демон. Больше деталей доступно в официальной документации.

Заключение

Получилось, все же, очень сжато — но уложить даже самый простой вводный курс по Spring в рамки одной статьи не очень просто. Надеюсь, это поможет кому-то сделать первый шаги в Spring-е, и хотя понять его фундаментальные концепции.

Как вы успели заметить, в тексте статьи много раз звучало слово «магия Spring». По сути своей, это очень «магический» фреймворк — даже взглянув на самую верхушку айсберга мы уже видели, что Spring много всего делает в фоне. Это является и плюсом, и минусом фреймворка. Плюс несомненно в том, что многие сложные вещи (очень многие) можно сделать одной аннотацией или зависимостью. Минус же это скрытая сложность — чтобы решить какие-то сложные проблемы, заставить фреймворк работать в крайних случаях или понимать все тонкости и аспекты нужно его неплохо знать.

Чтобы сделать этап «знать» как можно проще, Spring обладает отличной документацией, огромным сообществом, и чистыми исходниками, которые вполне можно читать. Если расположить Spring на шкале Рича Хики, он (Spring) несомненно попадет в easy, но уж точно не simple. Но для современного энтерпрайза (и не только энтерпрайза) он дает невероятные возможности чтобы получить production-ready приложение очень быстро и концентрироваться на логике приложения, а не инфраструктуры вокруг.

Источник