Пишем простое веб-приложение используя Spring MVC, Spring Data JPA и Hibernate
Привет, Хабр! Представляю Вашему вниманию перевод руководства «Spring MVC + Spring Data JPA + Hibernate — CRUD Example» автора Nam Ha Minh.
В этом руководстве по Java Spring вы узнаете, как настроить Spring MVC приложение для работы с Spring Data JPA, разработав простое веб-приложение, которое позволяет управлять информацией о клиентах.
По завершению этого руководства, вы сможете создать веб-приложение Java основанное на технологиях Spring MVC и Spring Data JPA, которое выглядит следующим образом:
Программы и технологии используемые в этом руководстве: Java 8, Apache Tomcat 9, MySQL Server 5.7, Eclipse IDE 4.7 (Oxygen), Spring Framework 5.1, Hibernate 5.4, Spring Data JPA 2.1.5 и Servlet 3.1.
Начнём с создания базы данных.
1. Создание базы данных
Мы будем использовать MySQL. В нашем пример мы будем работать с данными в таблице customer, которая находится в схеме с именем sales. Таблица customer имеет 4 поля: id, name, email и address:
Вы можете запустить следующий MySQL скрипт для создания схемы и таблицы:
2. Создание проекта в Eclipse
Создайте Dynamic Web Project в Eclipse, и конвертируйте его в проект Maven: для этого нажмите ПКМ по проекту, выберете Configure > Convert to Maven Project. В открывшемся диалоговом окне Create new POM введите следующую информацию:
— Group Id: net.codejava
— Artifact Id: CustomerManager
Также убедитесь, что версия JRE для проекта Java 8 или новее.
Затем, откройте pom.xml (файл Maven), чтобы настроить зависимости для этого проекта. Объявите свойства версий для Spring и Hibernate Frameworks:
Укажите зависимость для Spring Framework:
Для создания веб-приложений Spring MVC:
Для использования Spring Data JPA:
Мы используем Hibernate в качестве реализации JPA, поэтому добавим следующую зависимость:
Для того, чтобы приложение работало с MySQL, нам нужна зависимость для драйвера MySQL JDBC:
И теперь зависимости для Java Servlet, JSP и JSTL:
Создайте два Java пакета в корне проекта:
— net.codejava.config : для классов конфигурации.
— net.codejava.customer : для классов приложения.
3. Создание файла настройки JPA
И впишите в этот файл код представленный ниже:
Как вы можете видеть, мы указываем свойства для соединения с базой данных, такие как URL, user, password и класс JDBC драйвера. Так же обратите внимание, что имя SalesDB будет использоваться нами в коде конфигурации.
4. Создание Model Class
5. Конфигурация Spring MVC и Spring Data JPA
Далее, напишем Java код для настройки Spring MVC и Spring Data JPA. Мы будем использовать конфигурацию на основе Java, так как она проще, чем XML.
Настройка Spring Dispatcher Servlet
Для использования Spring MVC в нашем приложении, нам надо зарегистрировать Spring Dispatcher Servlet при запуске приложения, написав следующий класс:
Настройка Spring MVC
В этом классе мы создаём bean-компонент, который распознаёт представления (View), с помощью указания префикса и суффикса для этих представлений. Поэтому создайте каталог views внутри каталога WebContent/WEB-INF для хранения JSP файлов.
Здесь вы можете добавить и другие конфигурации Spring MVC.
Настройка Spring Data JPA
Здесь мы используем две важные аннотации:
Это минимальная необходимая конфигурация для использования Spring Data JPA.
Создание Repository Interface
7. Создание Service Class
Затем, создайте класс CustomerService :
Это похоже на магию, поскольку мы не пишем DAO код, но Spring Data JPA автоматически создаст реализацию во время выполнения.
8. Создание контроллера Spring MVC
Создайте класс CustomerContoroller для обработки всех запросов от клиентов:
Мы напишем методы обработки в следующих секциях.
9. Добавление списка клиентов
На домашней странице нашего приложения будут отображаться все клиенты, для этого добавьте соответствующий обрабатывающий метод в наш CustomerController класс:
Домашняя страница просмотра ( index.jsp ) должна выглядеть следующим образом:
10. Добавление нового пользователя
Для того, чтобы реализовать функцию создания нового клиента, нам нужно написать два метода-обработчика. И первый из них будет отображать новую форму для добавления клиента:
Напишем саму JSP форму с именем new_customer.jsp :
Теперь на главной странице у вас появится ссылка New Customer, при нажатии на которую вы увидите новую форму:
Второй метод-обработчик будет обрабатывать кнопку Save в этой форме:
Как вы можете видеть, она перенаправляет клиента на домашнюю страницу, после успешного сохранения пользователя.
11. Изменение данных пользователя
Чтобы реализовать функцию редактирования клиента, добавим следующий метод-обработчик в класс CustomerController :
Нажмите на гиперссылку Edit рядом с клиентом на домашней странице, вызовется форма редактирования клиента, которая будет выглядеть примерно вот так:
Метод-обработчик по-прежнему обрабатывает кнопку Save.
12. Удаление клиента
Для реализации функции удаления, напишите следующий метод-обработчик в классе CustomerController :
Нажмите на гиперссылку Delete рядом с клиентом на главной странице. Клиент удалится, а список обновится.
13. Поиск по клиентам
Наконец, давайте реализуем функцию поиска, которая позволяет пользователю искать клиентов, вводя ключевое слово. Функция поиска ищет ключевые слова в трёх полях: имя, email и адрес, для чего нам потребуется написать собственный метод в интерфейсе CustomerRepository :
Затем добавьте метод в класс CustomerService :
Теперь добавьте метод-обработчик в класс CustomerController :
И создайте страницу результата поиска search.jsp :
Для тестирования функции поиска, введите ключевое слово в поле поиска на домашней странице, и нажмите Enter. Вы увидите страницу результата поиска:
Выводы
В данном руководстве вы узнали как можно разработать веб-приложение Spring MVC, используя Spring Data JPA для доступа к данным. Как вы могли видеть, Spring Data JPA значительно уменьшает и упрощает код, который нам нужно писать.
Для сравнения, вот структура проекта в Eclipse IDE:
Java/Spring: Как полностью сгенерировать CRUD REST API с помощью Speedment
В этой статье вы узнаете, как с помощью Speedment создать полный CRUD REST API для базы данных.
С каждым годом становится все очевиднее, что Spring Framework является одним из наиболее широко используемых фреймворков для веб-разработки на Java.
С приближением следующего десятилетия самый популярный модуль Spring, Spring Boot, только что получил серьезное обновление. Новая версия Spring Boot «2.2.0» и 2020 год почти идеально подходят друг другу. Поэтому команда разработки Speedment восполнила пробел, обновив плагин для Spring Boot.
Если вы впервые слышите о Speedment, вы получите удовольствие, так как мы покажем, как плагин Speedment Spring Boot позволяет разработчикам без особых усилий создавать Spring приложения баз данных с помощью Speedment, ORM с мощным интерфейсом запросов на основе Stream API.
О Speedment
Speedment можно описать как ORM, которого заслуживает сообщество Java — набор инструментов для тех, кто любит быструю разработку и еще более быстрые приложения.
Благодаря использованию Java Stream API в качестве основного средства связи с выбранной базой данных, Speedment позволяет разработчикам с опытом работы с Java чувствовать себя как дома. Помимо простого в использовании API, Speedment предоставляет разработчикам графический инструмент, который генерирует для них модель предметной области в считанные секунды.
Если вас заинтересовал Speedment в целом, перейдите по следующей ссылке для получения подробной документации с примерами. Остальная часть этой статьи будет посвящена плагину для Spring Boot.
Spring Boot: Самый быстрый старт
Плагин Speedment Spring Boot существует уже некоторое время, но в Speedment 3.2.2 была представлена основная функция — возможность генерировать весь CRUD REST API непосредственно из вашей модели базы данных.
В зависимости от того, начинаете ли вы с нуля или у вас уже есть проект, шаги будут отличаться, но будьте уверены, что процесс интеграции будет простым независимо от состояния вашего проекта.
Если вы хотите интегрировать Spring Boot в существующий Speedment проект, вам необходимо добавить следующие 2 элемента в ваш pom.xml:
После добавления этих элементов при следующей регенерации модели вашего домена должна быть сгенерирована специфичекая для Speedment конфигурация Spring. Сгенерированная конфигурация управлят свойствами соединения с базой данных и регистрации бинов для различных менеджеров, сгенерированных Speedment.
Если вы начинаете проект с нуля, перейдите на инициализатор проекта, где для вас будет создан готовый проект для Spring Boot. Как вы будете настраивать проект, зависит от вас, но чтобы включить плагин Spring Boot в сгенерированный проект, убедитесь, что установлен флажок рядом с Spring в разделе плагинов. Когда конфигурация проекта будет вас устраивать, нажмите кнопку Download (Загрузить), и вы получите готовый к использованию архив проекта.
CRUD упрощается
Как только вы установите плагин, в инструменте Speedment будут доступны некоторые специфические параметры Spring Boot, которые можно использовать для настройки вашего REST API. Вы можете запустить инструмент Speedment, выполнив следующую команду:
Если вы впервые используете Speedment, возможно вы захотите ознакомиться с рабочим процессом, следуя краткому руководству «Hello Speedment».
По умолчанию инструмент Speedment не генерирует REST API. Чтобы сгенерировать CRUD REST API для конкретной таблицы, выберите таблицу в древовидном представлении и установите флажок «Generate @RestController» вместе с параметром «REST Enable Create/Update/Delete». При нажатии Generate (Генерировать) будет создан набор REST mappings — URL, которые реализуют CRUD операции для конкретной таблицы.
Вот и все! Ручное кодирование не требуется. Просто запустите сгенерированный Spring проект, выполнив команду:
Создание сущностей с использованием REST
Чтобы создать новую сущность, используя созданный вами REST API, вы должны выполнить запрос POST по пути, указанному в инструменте. По умолчанию имя этого пути совпадает с именем вашей таблицы, с префиксом имени вашей схемы. Если вы снимите флажок «REST Endpoint (Конечная точка REST)», вы можете указать произвольное имя пути. Тело запроса должно содержать пары ключ-значение в объекте JSON, где значения «REST Field Name (Имя поля REST)» из инструмента Speedment являются ключами.
Например, если у нас есть таблица с именем person с колонками id, name и age, мы отправим следующий запрос для создания новой сущности person:
Если значение колонки id генерируется автоматически (или использует последовательность), вы можете исключить ее из тела POST. Если вы хотите принудительно исключить определенный столбец из тела POST, щелкните соответствующий столбец в представлении дерева инструментов и снимите флажок «Include in Create Body (Включить в создание тела)» и заново создайте модель вашего домена. С другой стороны, если вы хотите обеспечить наличие определенного столбца в теле POST при выполнении запроса, отметьте «Required in Create Body (Обязательно в теле создания)» и заново создайте модель вашего домена.
Получение сущностей с помощью REST
Чтобы получить наш вновь созданную сущность, мы должны выполнить запрос GET по тому же пути, который использовался для создания сущности:
Выполненный запрос вернет JSON Array всех существующих сущностей. В нашем случае он вернул бы массив только с нашей единственной сущностью:
Продвинутые концепции, такие как фильтры и сортировщики, подробно описаны в официальной документации Speedment.
Обновление существующих сущностей с помощью REST
Обновление существующей сущности с использованием REST API выполняется аналогично созданию сущности. Вместо запроса POST мы выполняем запрос PATCH, и путь расширяется идентификатором сущности. Какой идентификатор нашей сущности зависит от колонки первичного ключа этой таблицы. Поскольку наша колонка PK (первичного ключа) является числовым типом, идентификатор нашей сущности будет целым числом.
Чтобы обновить сущность, которую мы создали в нашем предыдущем примере, мы выполним следующий запрос:
По умолчанию все колонки включены в тело PATCH (кроме колонки первичного ключа), но они не являются обязательными. Если вы хотите принудительно исключить определенный столбец из тела запроса, щелкните соответствующий столбец в представлении дерева инструментов и снимите флажок «Include in Update Body (Включить в тело обновления)» и заново создайте модель своего домена. С другой стороны, если вы хотите обеспечить наличие столбца в теле запроса, отметьте «Required in Update Body (Обязательно в теле обновления)» и обновите модель вашего домена.
Удаление сущностей с помощью REST
Удалить сущность с помощью REST API довольно просто — мы выполняем запрос DELETE по тому же пути, который используется для обновления сущностей.
Чтобы удалить сущность, который мы создали и обновили в предыдущих примерах, мы выполнили бы следующий запрос:
Резюме
Запуск новых проектов иногда может быть хлопотным. Как разработчики, мы хотим максимально избежать этих неудобств и погрузиться прямо в кодирование. С новым плагином Speed Boot Spring Boot разработчики могут ускорить запуск новых проектов, автоматически генерируя все необходимые конфигурации и контроллеры REST непосредственно из базы данных.
Мы надеемся, что вам понравилось это краткое руководство по новым функциям CRUD, которые предоставляет плагин Speedment Spring Boot. Если вас интересует более подробное объяснение новых функций, перейдите на официальную документацию, где вы найдете подробные объяснения и примеры новых функций CRUD.
Приложение Spring Boot CRUD с Thymeleaf
Узнайте, как создать простое приложение CRUD с помощью Spring Boot и Thymeleaf.
1. Обзор
Реализация DAO слоев, которые обеспечивают функциональность CRUD для JPA сущностей, может быть повторяющейся, трудоемкой задачей, которой мы хотим избежать в большинстве случаев. К счастью, Spring Boot упрощает создание CRUD-приложений с помощью уровня стандартных репозиториев CRUD на основе JPA.
Дальнейшее чтение:
Параметры запроса пружины с помощью Thymeleaf
Изменение каталога шаблонов Thymeleaf в весенней загрузке
2. Зависимости Maven
В этом случае мы будем полагаться на spring-boot-starter-parent для простого управления зависимостями, управления версиями и настройки подключаемых модулей. В результате нам не нужно будет указывать версии зависимостей проекта в вашем pom.xml файл, за исключением переопределения версии Java:
3. Доменный Уровень
Поскольку все зависимости проекта уже установлены, давайте теперь реализуем наивный доменный уровень.
Для простоты этот слой будет включать один единственный класс, который будет отвечать за моделирование Пользователей сущностей:
4. Уровень Хранилища
На данный момент наш образец веб-приложения ничего не делает. Но это скоро изменится.
Чтобы предоставить нашему приложению базовую функциональность CRUD для Пользовательских объектов, все, что нам нужно сделать, это расширить интерфейс CrudRepository :
5. Уровень Контроллера
Первый отобразит форму регистрации пользователя, в то время как второй сохранит новую сущность в базе данных после проверки ограниченных полей.
Если объект не пройдет проверку, форма регистрации будет отображена повторно. В противном случае, как только объект будет сохранен, список сохраненных объектов будет обновлен в соответствующем представлении:
Нам также понадобится сопоставление для /индекса URL:
Если сущность существует, она будет передана в качестве атрибута модели в представление формы обновления, следовательно, форма может быть заполнена значениями полей имя и электронная почта :
Первый сохранит обновленную сущность в базе данных, в то время как последний удалит данную сущность.
В любом случае список сохраняемых объектов будет соответствующим образом обновлен:
6. Слой Представления
На данный момент мы реализовали класс функционального контроллера, который выполняет операции CRUD над Пользователями сущностями. Даже в этом случае в этой схеме все еще отсутствует компонент: слой представления.
В папке src/main/ресурсы/шаблоны нам нужно создать HTML-шаблоны, необходимые для отображения формы регистрации, формы обновления и отображения списка сохраняемых Пользователей сущностей,
Как указано во введении, мы будем использовать Thymeleaf в качестве базового механизма шаблонов для анализа файлов шаблонов.
Вот соответствующий раздел add-user.html файл:
Наконец, у нас есть index.html файл, в котором отображается список сохраненных объектов вместе со ссылками для редактирования и удаления существующих:
7. Запуск приложения
Наконец, давайте определим точку входа приложения. Как и большинство приложений Spring Boot, мы можем сделать это с помощью простого старого метода main() :
Если сборка успешно скомпилирована мы должны увидеть базовую панель управления пользователями CRUD со ссылками для добавления новых объектов, а также для редактирования и удаления существующих.
8. Заключение
В этом уроке мы узнали, как создать базовое веб-приложение CRUD с помощью Spring Boot и Thymeleaf.
Абстрактный CRUD от репозитория до контроллера: что ещё можно сделать при помощи Spring + Generics
Совсем недавно на Хабре мелькнула статья коллеги, который описал довольно интересный подход к совмещению Generics и возможностей Spring. Мне она напомнила один подход, который я использую для написания микросервисов, и именно им я решил поделиться с читателями.
На выходе мы получаем транспортную систему, для добавления в которую новой сущности нужно будет ограничиться инициализацией одного бина в каждом элементе связки репозиторий-сервис-контроллер.
Сразу ресурсы.
Ветка, как я не делаю: standart_version.
Подход, о котором рассказывается в статье, в ветке abstract_version.
Я собрал проект через Spring Initializr, добавив фреймворки JPA, Web и H2. Gradle, Spring Boot 2.0.5. Этого будет вполне достаточно.
Для начала, рассмотрим классический вариант транспорта от контроллера до репозитория и обратно, лишённый всякой дополнительной логики. Если же Вы хотите перейти к сути подхода, проматывайте вниз до абстрактного варианта. Но, всё же, рекомендую прочитать статью целиком.
Классический вариант.
В ресурсах примера представлены несколько сущностей и методов для них, но в статье пусть у нас будет только одна сущность User и только один метод save(), который мы протащим от репозитория через сервис до контроллера. В ресурсах же их 7, а вообще Spring CRUD / JPA Repository позволяют использовать около дюжины методов сохранения / получения / удаления плюс Вы можете пользоваться, к примеру, какими-то своими универсальными. Также, мы не будем отвлекаться на такие нужные вещи, как валидацию, мапинг dto и прочее. Это Вы сможете дописать сами или изучить в других статьях Хабра.
Domain:
Repository:
Service:
Service (имплементация):
Controller:
У нас получился некий набор зависимых классов, которые помогут нам оперировать сущностью User на уровне CRUD. Это в нашем примере по одному методу, в ресурсах их больше. Этот нисколько не абстрактный вариант написания слоёв представлен в ветке standart_version.
Допустим, нам нужно добавить ещё одну сущность, скажем, Car. Мапить на уровне сущностей мы их друг к другу не будем (если есть желание, можете замапить).
Для начала, создаём сущность.
Потом создаём репозиторий.
Потом имплементация сервиса…… Контроллер………
Да, можно просто скопипастить те же методы (они же у нас универсальные) из класса User, потом поменять User на Car, потом проделать то же самое с имплементацией, с контроллером, далее на очереди очередная сущность, а там уже выглядывают ещё и ещё… Обычно устаёшь уже на второй, создание же служебной архитектуры для пары десятков сущностей (копипастинг, замена имени сущности, где-то ошибся, где-то опечатался. ) приводит к мукам, которые вызывает любая монотонная работа. Попробуйте как-нибудь на досуге прописать двадцать сущностей и Вы поймёте, о чём я.
И вот, в один момент, когда я как раз увлекался дженериками и типовыми параметрами, меня осенило, что процесс можно сделать гораздо менее рутинным.
Итак, абстракции на основе типовых параметров.
Смысл данного подхода заключается в том, чтобы вынести всю логику в абстракцию, абстракцию привязать к типовым параметрам интерфейса, а в бины инжектить другие бины. И всё. Никакой логики в бинах. Только инжект других бинов. Этот подход предполагает написать архитектуру и логику один раз и не дублировать её при добавлении новых сущностей.
Начнём с краеугольного камня нашей абстракции — абстрактной сущности. Именно с неё начнётся цепочка абстрактных зависимостей, которая послужит каркасом сервиса.
У всех сущностей есть как минимум одно общее поле (обычно больше). Это ID. Вынесем это поле в отдельную абстрактную сущность и унаследуем от неё User и Car.
AbstractEntity:
Не забудьте пометить абстракцию аннотацией @MappedSuperclass — Hibernate тоже должен узнать, что это абстракция.
С Car, соответственно, то же самое.
В каждом слое у нас, помимо бинов, будет один интерфейс с типовыми параметрами и один абстрактный класс с логикой. Кроме репозитория — благодаря специфике Spring Data JPA, здесь всё будет намного проще.
Первое, что нам потребуется в репозитории — общий репозиторий.
CommonRepository:
В этом репозитории мы задаём общие правила для всей цепочки: все сущности, участвующие в ней, будут наследоваться от абстрактной. Далее, для каждой сущности мы должны написать свой репозиторий-интерфейс, в котором обозначим, с какой именно сущностью будет работать эта цепочка репозиторий-сервис-контроллер.
UserRepository:
На этом, благодаря особенностям Spring Data JPA, настройка репозитория заканчивается — всё будет работать и так. Далее следует сервис. Мы должны создать общий интерфейс, абстракцию и бин.
CommonService:
AbstractService:
Здесь мы переопределяем все методы, а также, создаём параметризированный конструктор для будущего репозитория, который мы переопределим в бине. Таким образом, мы уже используем репозиторий, который мы ещё не определили. Мы пока не знаем, какая сущность будет обработана в этой абстракции и какой репозиторий нам потребуется.
UserService:
В бине мы делаем заключительную вещь — явно определяем нужный нам репозиторий, который потом вызовется в конструкторе абстракции. И всё.
При помощи интерфейса и абстракции мы создали магистраль, по которой будем гонять все сущности. В бине же мы подводим к магистрали развязку, по которой будем выводить нужную нам сущность на магистраль.
Контроллер строится по тому же принципу: интерфейс, абстракция, бин.
CommonController:
AbstractController:
UserController:
Это вся структура. Она пишется один раз.
Что дальше?
И вот теперь давайте представим, что у нас появилась новая сущность, которую мы уже унаследовали от AbstractEntity, и нам нужно прописать для неё такую же цепочку. На это у нас уйдёт минута. И никаких копипаст и исправлений.
Возьмём уже унаследованный от AbstractEntity Car.
CarRepository:
CarService:
CarController:
Как мы видим, копирование одинаковой логики состоит в простом добавлении бина. Не надо заново писать логику в каждом бине с изменением параметров и сигнатур. Они написаны один раз и работают в каждом последующем случае.
Заключение
Конечно, в примере описана этакая сферическая ситуация, в которой CRUD для каждой сущности имеет одинаковую логику. Так не бывает — какие-то методы Вам всё равно придётся переопределять в бине или добавлять новые. Но это будет происходить от конкретных потребностей обработки сущности. Хорошо, если процентов 60 от общего количества методов CRUD будет оставаться в абстракции. И это будет хорошим результатом, потому что чем больше мы генерим лишнего кода вручную, тем больше времени мы тратим на монотонную работу и тем выше риск ошибки или опечатки.
Надеюсь, статья была полезна, спасибо за внимание.