С чего начать изучение spring framework
Как я изучаю фреймворк Spring (помощь начинающим — дело рук самих начинающих)
Я поставил себе цель изучить фреймфорк Spring для языка Java. Во время изучения решил проверить на себе алгоритм обучения Ричарда Фейнмана: организовать-упростить-обучить другого. В общем, я стал записывать серию коротких уроков для начинающих по работе в Spring. Для желающих повторить выложил исходный код.
Урок 01. Разбираемся с IoC
Итак, соберем вместе поэтов, пускай сочиняют и читают нам свои стихи.
Для начала объявим интерфейс, генерирующий стихи src\main\java\spring\interfaces\Lyricist.java:
Реализуем этот интерфейс в классе src\main\java\spring\impls\Mayakovsky.java:
Пропишем, что будем создавать конкретный объект Mayakovsky в конфигурационном xml-файле src\main\resources\ApplicationContext.xml:
Связали id LyricistBean1 c именем класса Mayakovsky. Почти все готово, не хватает только вызывающего класса src\main\java\spring\main\Start.java:
В классе Start мы прочитали наш конфигурационный файл, создали экземпляр поэта по имени бина LyricistBean1. Получили экземпляр поэта Mayakovsky. Функция Generate() вернула нам бессмертные строки:
А вы
ноктюрн сыграть
могли бы
на флейте водосточных труб?
Урок 02. Выбор создаваемого экземпляра через конфигурационный файл
Допустим, друг помог нам и предоставил другую реализацию нашего интерфейса Lyricist src\main\java\spring\impls\Poushkin.java:
Изменим в конфигурационном файле ApplicationContext.xml слово Mayakovsky на слово Poushkin.
Запускаем программу. Получаем без пересборки совсем другой результат:
Я помню чудное мгновенье
Передо мной явилась ты,
Как мимолетное виденье,
Как гений чистой красоты.
Урок 03. Бины в коде, а не в конфигурационном файле
Допустим, нам не нравится отдавать выбор создаваемого класса поэта в руки судьбы в конфигурационный файл.
Изменим класс Poushkin.java
Осталось чуть-чуть исправить конфигурационный файл ApplicationContext.xml:
1. Добавим сверху пространство имен context: xmlns:context=«www.springframework.org/schema/context»;
2. Удалим ненужную строку: />
3. Добавим вместо нее команду автоматически добавлять в программу бины из всех классов, расположенных в каталоге spring.impls:
В итоге файл ApplicationContext.xml должен выглядеть вот так:
Запускаем. Получаем тот же результат, что и в предыдущем уроке.
Урок 04. Конфигурационный класс
Избавимся совсем от xml-файла.
Все настройки могут находиться и в java-классе. Иногда это удобно.
Добавим специальный настроечный класс src\main\java\spring\main\LyricistConfiguration.java в нашу программу:
@ComponentScan показывает, в каком каталоге искать бины.
@Configuration сообщает, что наш класс специальный, конфигурационный.
Все, xml-файл больше не нужен. Осталось сообщить эту новость нашему основному классу:
Все запускается и по-прежнему выдает бессмертные Пушкинские строки. Все работает. Но уже без xml.
Урок 05. Singleton и Prototype
Исследуем возможности конфигурационного файла. Поэтому вернемся пока к проекту из второго урока. Попробуем в Start.java создать два экземпляра класса Poushkin и удостоверимся, что великий поэт один и тот же:
И стихи одни и те же, и хэш-код сорпадает. Все в порядке.
Добавим в наш проект простого гражданина, не пишущего стихи src\main\java\spring\impls\SimpleMan.java:
Зарегистрируем класс в конфигурационном файле (сразу после первого бина)
Гражданин все время один и тот же. Непорядок…
Изменим регистрацию бина в конфигурационном файле, добавив волшебное слово scope=«prototype»
В итоге файл src\main\resources\ApplicationContext.xml будет выглядеть так:
Теперь все в порядке. Граждане каждый раз разные. А Пушкин всегда один.
Внимательные заметили, что в первом бине добавилась настройка scope=«singleton», но это настройка используется по умолчанию, поэтому ее можно и не писать.
На сегодня все. Если данный пост пройдет премодерацию, а у меня появятся время и силы, будет продолжение про AOP, JDBC, транзакции, MVC и прочие премудрсти.
Реализация Spring Framework API с нуля. Пошаговое руководство для начинающих. Часть 1
Spring Framework является одним из самых сложных фремворков для понимания и изучения. Большинство разработчиков изучают его медленно, через практические задачи и гугл. Этот подход не эффективен, так как не даёт полной картины и при этом требует больших затрат.
Я хотел бы предложить вам принципиально новый подход к изучению Спринга. Он заключается в том, что человек проходит через серию специально подготовленных туториалов и самостоятельно реализует функционал спринга. Особенность этого подхода в том, что он, помимо 100%-го понимания изучаемых аспектов Spring даёт ещё большой прирост в Java Core (Annotations, Reflection, Files, Generics).
Статья подарит вам незабываемые ощущения и позволит почувствовать себя разработчиком Pivotal. Шаг за шагом, вы сделаете ваши классы бинами и организуете их жизненный цикл (такой же, как и в реальном спринге). Классы, которые вы будете реализовывать — BeanFactory, Component, Service, BeanPostProcessor, BeanNameAware, BeanFactoryAware, InitializingBean, PostConstruct, PreDestroy, DisposableBean, ApplicationContext, ApplicationListener, ContextClosedEvent.
Немного о себе
Меня зовут Ярослав, и я Java Developer с 4-х летним опытом работы. На данный момент я работаю в компании EPAM Systems (СПБ), и с интересом углубляюсь в те технологии, которые мы используем. Довольно часто приходится иметь дело со спрингом, и я вижу в нём некоторую золотую середину, в которой можно разиваться (Java все итак нормально знают, а слишком специфические инструменты и технологии могут приходить и уходить).
Пару месяцев назад я прошёл сертификацию Spring Professional v5.0 (без прохождения курсов). После этого я задумался над тем, как можно обучать спрингу других людей. К сожалению, на данный момент нет эффективной методики обучения. У большинства разработчиков складывается весьма поверхностное представление о фреймворке и его особенностях. Дебажить исходники спринга слишком тяжело и абсолютно не эффективно с точки зрения обучения (я как-то увлекался этим). Сделать 10 проектов? Да, вы где-то сможете углубить свои знания и получите много практического опыта, но многое из того, что «под капотом», так и не откроется перед вами. Читать книгу Spring in Action? Круто, но затратно по усилиям. Я вот проработал её 40% (во время подготовки к сертификации), но это было не просто.
Единственный способ понять что-то до конца — самостоятельно разработать это. Недавно у меня появилась идея о том, что можно провести человека через интересный туториал, который будет курировать разработку своего DI-фреймворка. Главная его особенность будет заключаться в том, что API будет совпадать с изучаемым API. Офигенность данного подхода в том, что помимо глубокого (без пробелов) понимания спринга, человек получит ОГРОМНОЕ количество опыта по Java Core. Признаюсь честно, я сам много всего нового узнал во время подготовки статьи, как по Spring, так и по Java Core. Давайте приступим к разработке!
Проект с нуля
Итак, первое, что нужно сделать — это открыть любимую IDE и создать проект с чистого листа. Никаких Maven, никаких сторонних библиотек мы подключать не будем. Даже Spring-зависимости подключать не будем. Наша цель — разработать API, максимально похожий на Spring API, и реализовать его самостоятельно.
В чистом проекте создайте 2 главных пакета. Первый пакет — ваше приложение ( com.kciray ), и класс Main.java внутри него. Второй пакет — org.springframework. Да, мы будем дублировать структуру пакетов оригинального спринга, название его классов и их методов. Есть такой интересный эффект — когда вы создаете что-то свое, это свое начинает казаться простым и понятным. Потом, когда вы будете работать в больших проектах, вам будет казаться, что там все создано на основе вашей заготовки. Такой подход может очень положительно сказаться на понимании работы системы в целом, её улучшении, исправлении багов, решении проблем и так далее.
Если будут вознить какие-то проблемы, работающий проект можете взять тут.
Создаём контейнер
Обратите внимание на то, что BeanFactory и FactoryBean — это разные вещи. Первое — это фабрика бинов (контейнер), а второе — это бин-фабрика, который сидит внутри контейнера и тоже производит бины. Фабрика внутри фабрики. Если вы путаетесь между этими определениями, можете запомнить, что в английском языке второе существительное является ведущим, а первое — служит чем-то типа прилагательного. В слове BeanFactory Главным словом является фабрика, а в FactoryBean — бин.
Теперь нам надо сделать так, чтобы наш контейнер ( BeanFactory ) обнаружил наши классы, создал их за нас и инжектировал один в другой. Операции типа new ProductService() должны находится внутри контейнера и делаться за разработчика. Давайте используем самый современный подход (сканирование классов и аннотации). Для этого нам нужно ручками создать аннотацию @Component ( пакет org.springframework.beans.factory.stereotype ).
По умолчанию аннотации не загружаются в память во время работы программы ( RetentionPolicy.CLASS ). Мы изменили данное поведение через новую политику удержания ( RetentionPolicy.RUNTIME ).
Сразу хочу предупредить, что будет много проверяемых исключений, поэтому будьте готовы их оборачивать. Но для начала, давайте определимся, чего мы хотим. Мы хотим добавить специальный метод в BeanFactory и вызывать его в Main :
Наверно вы уже заметили, что пакеты разделяются точкой, а файлы — прямым слешем. Нам надо преобразовать пакетный путь в путь к папке, и получить что-то типа List (пути в вашей файловой системе, по которым можно искать class-файлы).
Поехали дальше. Нам надо извлечь папки и проработать содержимое каждой из них. Преобразуем URL в файл, а затем получаем его имя. Тут надо отметить, что мы не будем сканировать вложенные пакеты, чтобы не усложнять код. Можете усложнить себе задачу и сделать рекурсию, если есть желание.
Дальше, нам нужно получить название файла без расширения. На дворе 2018 год, Java много лет развивала File I/O (NIO 2), но до сих пор не может отделить расширение от имени файла. Приходится свой велосипед создавать, т.к. мы решили не использовать сторонние библиотеки вроде Apache Commons. Давайте используем старый дедовский способ lastIndexOf(«.») :
Далее, мы можем по полному имени класса получить объект класса (для этого вызываем класс класса Class ):
Окей, теперь наши классы в наших руках. Далее, осталось только выделить среди них те, что имеют аннотацию @Component :
Запустите и проверьте. В консоли должно быть что-то вроде этого:
Теперь убедитесь в том, что всё работает. Контейнер должен создавать бины, и они должны извлекаться по имени. Обратите внимание на то, что название вашего метода instantiate() и название метода classObject.newInstance(); имеют общий корень. Более того, instantiate() — это часть жизненного цикла бина. В джаве всё взаимосвязано!
Наполняем свойства
Далее, добавим её к свойству:
Теперь нам нужно научить наш BeanFactory находить эти аннотации и инжектировать зависимости по ним. Добавим отдельный метод для этого, и вызовем его из Main :
Далее, нам надо ещё разок пройтись по всем бинам и посмотреть их тип — вдруг это тот тип, который хочет себе взять наш бин. Да, у нас получается трехмерный цикл!
Теперь запустите ваш проект и убедитесь, что при вызове productService.getPromotionsService() вместо null возвращается наш бин.
Поддерживаем бины, знающие о своем имени
Бывают случаи, когда внутри бина нужно получить его имя. Такая потребность возникает не часто, т.к. бины, по своей сути, не должны знать друг о друге и о том, что они бины. В первых версиях спринга предполагалось, что бин — это POJO (Plain Old Java Objec, старый добрый Джава-объект), а вся конфигурация вынесена в XML-файлы и отделена от реализации. Но мы реализуем данный функционал, так как инъекция имени — это часть жизненного цикла бина.
Как нам узнать, какой бин хочет узнать, как его зовут, а какой не хочет? Первое, что приходит в голову — это сделать новую аннотацию типа @InjectName и лепить её на поля типа String. Но это решение будет слишком общим и позволяет выстрелить себе в ногу много раз (разместить эту аннотацию на полях неподходящих типов (не String), или же пытаться инжектировать имя в несколько полей в одном классе). Есть другое решение, более аккуратное — создать специальный интерфейс с одним методом-сеттером. Все бины, что его реализуют — получает своё имя. Создайте класс BeanNameAware в пакете org.springframework.beans.factory :
Далее, пускай наш PromotionsService его реализует:
И, наконец, добавим новый метод в фабрику бинов. Тут всё просто — мы проходимся по нашим бинам-синглтонам, проверяем, реализует ли бин наш интерфейс, и вызываем сеттер:
Запустите и убедиесь, что всё работает:
Надо отметить, что в спринге есть и другие подобные интерфейсы. Я рекомендую вам самостоятельно реализовать интерфейс BeanFactoryAware, который позволит бинам получать ссылку на фабрику бинов. Реализуется он аналогично.
Инициализируем бины
Добавляем пост-процессоры
Представьте себя на месте первых разработчиков спринга. Ваш фреймворк растёт и пользуется огромной популярностью среди девелоперов, на почту каждый день приходят письма с просьбами добавить ту или иную полезную фичу. Если для каждой такой фичи добавлять свой собственный интерфейс и проверять его в жизенном цикле бина, то он (жизненный цикл) окажется засоренным ненужной информацией. Вместо этого, мы можем создать один универсальный интерфейс, который позволит добавлять выполнение некоторой логики (абсолютно любой, будь то проверка на аннотацию, замена бина на другой бин, установка некоторых особых свойств и так далее).
Давайте подумаем, для чего предназначен данный интерфейс. Он должен производить некоторую пост-обработку бинов, следовательно его можно назвать BeanPostProcessor. Но перед нами стоит непростой вопрос — когда следует выполнять логику? Ведь мы можем выполнить её до инициализации, а можем выполнить и после. Для одних задач лучше подходит первый вариант, для других — второй… Как быть?
Мы можем позволить оба варианта сразу. Пускай один пост-процессор несёт две логики, два метода. Один выполняется до инициализации (до метода afterPropertiesSet() ), а другой — после. Теперь давайте задумаемся над самими методами — какие параметры у них должны быть? Очевидно, что там должен быть сам бин ( Object bean ). Для удобства, кроме бина можно передавать имя этого бина. Вы же помните, что бин сам по себе не знает о своём имени. И мы не хотим заставлять все бины реализовывать интерфейс BeanNameAware. Но, на уровне пост-процессора, имя бина может очень даже пригодиться. Поэтом удобавляем его как второй параметр.
А что должен возвращать метод при пост-обработке бина? Сделаем так, чтобы он возвращал сам бин. Это даёт нам супер-гибкость, ведь вместо бина можно подсунуть прокси-объект, который оборачивает его вызовы (и добавляет секьюрити). А можно и вовсе вернуть другой объект, пересоздав бин заново. Разработчикам даётся очень большая свобода действия. Ниже представлена окончательная версия спроектированного интерфейса:
Далее, нам нужно добавить список из прост-процессоров к нашей фабрике бинов и возможность добавлять новые. Да, это обычный ArrayList.
Теперь поменяем метод initializeBeans так, чтобы он учитывал пост-процессоры:
Давайте создадим небольшой пост-процессор, который просто трассирует вызовы в консоль, и добавим его в нашу фабрику бинов:
Обязательно создавайте все аннотации и пакеты (даже javax.annotation) вручную, не подключайте зависимости! Это поможет вам увидеть разницу между ядром спринга и его расширениями (поддержка javax), и запомнить её. Это позволит придерживаться одного стиля в будущем.
Вам будет интересен тот факт, что в реальном спринге аннотация @PostConstruct именно так и реализована, через пост-процессор CommonAnnotationBeanPostProcessor. Но не подглядывайте туда, напишите свою реализацию.
Полный жизненный цикл бина
Вот мы и реализовали полный жизненный цикл бина, в его современном виде. Я надеюсь, что такой подход поможет вам его запомнить.
Наш любимый контекст
Статья получилась слишком большой и содержимое стало обрезаться, поэтому я поместил информацию по контексту под спойлер.
На самом деле, информация о типах сохраняется в метаданных класса, и очень даже успешно извлекается через рефлексию. Для начала, нам нужно получить список из интерфейсов, которые данный бин реализует, и отфильтровать среди них те, которые имеют параметры:
Далее, мы всего лишь извлекаем тип первого параметра, и убеждаемся, что он — наш класс события. Если это так, мы получаем наш метод через рефлексию и вызываем его:
Пускай один из ваших классов реализует интерфейс ApplicationListener:
Далее, тестируете ваш контекст в Main и убеждаетесь, что он также работает, и событие отправляется:
Заключение
Изначально я планировал данную статью для Baeldung на английском, но потом подумал, что аудитория хабры может положительно оценить данный подход к обучению. Если вам понравились мои идеи, обязательно поддержите статью. Если она наберёт рейтинг более 30, то обещаю продолжение. При написании статьи, я старался показать именно те знания Spring Core, которе используются наиболее часто, а также с опорой на Core Spring 5.0 Certification Study Guide. В будущем, с помощью таких туториалов можно покрыть всю сертификацию и сделать спринг более доступным для Java-разработчиков.
Update 10/05/2018
Мне постоянно приходят письма с вопросами «а когда продолжение, мы его ждём». Но вот времени совсем нету, и другие личные проекты в приоритете. Однако, если кому-то из вас действительно понравилась идея, вы можете изучить узкий раздел спринга и написать статью-продолжение. Если у вас нету аккаунта хабры, то я могу опубликовать статью от моего акка или помочь вам получить инвайт.
Распределение тем:
Spring Container — [имя пользователя]
Spring AOP — [имя пользователя]
Spring Web — [имя пользователя]
Spring Cloud — [имя пользователя]
Учебное пособие по Spring Framework: начало работы со Spring
Несмотря на то, что Spring Framework часто забывают как устаревший, он по-прежнему остается популярным инструментом разработки приложений, которым пользуются корпоративные компании по всему миру. Spring предлагает беспрецедентный контроль, первоклассную безопасность и экономящую время систему зависимостей с использованием Spring Beans.
Тем не менее, Spring, как известно, труден для изучения из-за большого количества опций и сложного набора инструментов.
Сегодня мы поможем вам начать свой путь разработки Spring с учебника для начинающих о том, как и зачем использовать Spring. В конце концов, мы даже поможем вам начать работу над вашим первым весенним портфельным проектом.
Что такое Spring Framework?
Spring — это легкая среда разработки приложений с открытым исходным кодом, использующая Java Enterprise Edition (Java EE) и модель Enterprise JavaBeans (EJB).
Spring часто называют «фреймворком», потому что он поддерживает другие интегрированные фреймворки в экосистеме Java, такие как Struts, Hibernate и Tapestry. Spring поставляется во многих вариантах, которые адаптированы для конкретных целей, таких как Spring MVC, Spring Boot или Spring Security.
Spring известен своими системами внедрения зависимостей и инверсии управления (IoC), которые позволяют с легкостью создавать крупномасштабные слабосвязанные приложения. Spring особенно подходит для финансовых и корпоративных приложений благодаря своей скорости, безопасности и простоте построения транзакционных систем. Ведущими работодателями разработчиков Spring являются Citibank, eBay, Visa и JP Morgan.
В целом Spring Framework позволяет создавать приложения масштаба предприятия, которые являются безопасными и могут автоматически обрабатывать низкоуровневые функции, такие как поддержание жизненных циклов контейнеров и управление зависимостями.
Преимущества Spring
Недостатки Spring
Многие из этих недостатков были устранены с помощью изобретения модуля Spring Boot, который очень самоуверен и предназначен для микросервисных архитектур.
Большинство современных Spring-приложений построены на Boot, но есть много старых приложений, которые все еще обслуживаются давними компаниями.
Особенности Spring
Архитектура и компоненты Spring
Давайте разберем основные части приложения Spring Framework, чтобы помочь вам увидеть общую картину.
Beans
Spring Beans — это экземпляры классов, которыми управляет Spring. Они являются наиболее фундаментальным компонентом программы Spring.
Традиционно объекты создают личные экземпляры своих зависимостей. Spring управляет всеми зависимостями объекта и создает экземпляр объекта в bean-компоненте после внедрения необходимых зависимостей. @ComponentАннотаций является наиболее распространенным методом определения бобов.
У bean-компонентов есть установленный жизненный цикл и видимость в зависимости от их области действия. Существует шесть типов областей: синглтон, прототип, запрос, сеанс, приложение и веб-сокет. Одноэлементные и прототипные области могут использоваться в любом приложении, в то время как последние четыре области доступны только для веб-приложения.
Область видимости bean-компонента по умолчанию — singleton, в которой только один экземпляр bean-компонента создается и кэшируется в памяти. Несколько запросов к компоненту возвращают общую ссылку на один и тот же компонент. Напротив, область видимости прототипа приводит к созданию новых bean-компонентов всякий раз, когда запрос на bean-компонент выполняется в контексте приложения.
Autowiring
Метод Spring по внедрению бобов в одно и другое. Spring идентифицирует зависимость выбранного bean-компонента, ищет совпадение, а затем заполняет зависимость. @AutowiredАннотаций сообщает Spring, чтобы найти и внедрить сотрудничающий боб в другой. Если доступно более одного bean-компонента одного типа, Spring выдает ошибку.
В следующем сценарии Spring обнаруживает два bean-компонента типа Operator:
IoC Container
Контейнер IoC — это платформа, которая обеспечивает функциональность инверсии управления. Контейнер IoC управляет bean-компонентами и создает все необходимые экземпляры.
Например, у нас есть класс, Vehicleкоторый зависит от другого класса, Engine.
С IoC программисту нужно только упомянуть зависимость, а Spring сделает все остальное. Контейнер IoC будет создавать экземпляры обоих классов и внедрять Engineих Vehicleв качестве зависимости.
Модули Spring и проекты Spring
Модули — это наборы инструментов, сгруппированные по назначению. Разработчики могут указать, какие модули помимо базового набора они хотели бы импортировать в качестве зависимостей для любого конкретного приложения.
Модули организованы в группы, называемые проектами. Каждый проект содержит модули, которые предназначены для работы на определенной платформе или типе приложения. Системы проектов и модулей помогают сохранить вашу программу легкой, поскольку вы можете загружать только те инструменты, которые используются в приложении.
Модули базовой архитектуры Spring Project показаны ниже, сгруппированные по их слоям:
Контейнер Spring Core включает 4 модуля, необходимых для использования Spring: Beans, Core, Context и Spring Expression Language (SpEL). Эти модули отвечают за основные функции среды Spring, такие как инверсия управления (IoC), внедрение зависимостей, интернационализация, а также за поддержку запросов к объекту во время выполнения.
Уровень доступа / интеграции Spring Data обеспечивает поддержку взаимодействия с базами данных и управления данными. Он состоит из 4 основных частей:
Веб-уровень содержит модули Веб, Сервлеты, Портлеты и Сокеты, используемые для создания веб-приложений.
Модуль Test обращается к сквозной проблеме модульного тестирования. Платформа Spring Test поддерживает тестирование с помощью JUnit, TestNG, а также создание фиктивных объектов для изолированного тестирования кода.
Модуль AOP предоставляет функции аспектно-ориентированного программирования, такие как перехват методов, pointcut, безопасность и функции ведения журнала. Spring имеет собственный модуль под названием Spring AOP, который предлагает базовые функциональные возможности аспектно-ориентированного программирования. Расширенная функциональность АОП может быть реализована за счет интеграции с AspectJ. АОП включает в себя комплексные проблемы бизнес-логики.
Помимо этого базового проекта, Spring включает проекты для всех основных вариантов использования. Эти проекты включают модули, которые слишком нишевые для базового проекта, но включают бесценные API-интерфейсы и функциональные возможности для целевого использования.
Например, Spring Cloud позволяет разрабатывать собственные облачные приложения, которые можно динамически настраивать и развертывать. Он предоставляет функциональные возможности для обработки общих шаблонов в распределенных системах. Другие проекты включают Spring Boot, Spring Security, Spring DAO, Spring Context и многие другие.
Начать работу с Spring
Теперь мы познакомим вас с вашим первым приложением Spring: простая система рекомендаций по фильмам. Настроить новый проект с помощью Spring Framework сложно, потому что вам нужно настроить полную архитектуру вручную, включая то, какие зависимости Apache Maven использовать, использовать ли XML или Java, и вы должны установить веб-сервер, такой как Tomcat.
Вместо этого мы будем использовать проект Spring Boot для автоматизации большей части процесса установки и использования его встроенного веб-сервера.
Как начать свой проект
Мы будем использовать Spring Initializr, чтобы быстро создать проект Spring Boot, используя его простое меню выбора. Сначала перейдите в start.spring.io. Вы найдете интерфейс меню, подобный приведенному ниже, с выбором настроек и полями метаданных.
Для этого проекта мы выберем «Maven Project», выберем Java в качестве нашего языка и выберем последнюю версию Spring Boot. На данный момент избегайте версий «SNAPSHOT», потому что они проходят альфа- или бета-тестирование. В разделе «Метаданные проекта» введите io.datajek.springbasics»GroupID» и movie-recommmender-system»ArtifactID«. Идентификатор группы и идентификатор артефакта — это в основном имя пакета и имя класса. Обычно вы добавляете зависимости модулей в разделе «Зависимости», но для этого проекта требуется только Spring по умолчанию. инструменты.
После того, как вы все ввели, нажмите «Создать», чтобы создать zip-файл с архитектурой настройки. Разархивируйте папку в желаемое место на жестком диске. Эта папка будет содержать pom.xmlфайл для импорта в Eclipse IDE. Через короткое время вы увидите следующую иерархию:
Поздравляем, вы создали свое первое приложение Spring с помощью Spring Boot!
Добавление зависимостей
Теперь мы добавим простую реализацию рекомендателя фильмов с использованием системы зависимостей Spring. Программа примет название фильма в качестве входных данных и вернет три названия фильмов того же жанра. А пока мы жестко закодируем наш вывод, чтобы вы могли сосредоточиться на изучении структуры программы.
Сначала создайте новый класс в src/main/javanamed RecommenderImplementation.
Затем мы добавим recommendMoviesметод в RecommenderImplementation. recommendMoviesМетод будет принимать строку заголовка фильма в качестве входных данных и возвращает три рекомендации в массиве String.
Используйте жестко запрограммированную реализацию ниже:
Теперь создайте экземпляр RecommenderImplementationкласса в MovieRecommenderSystemApplicationфайле, а затем вызовите recommendMoviesметод через RecommenderImplementationкласс.
Затем мы реализуем фильтрацию на основе содержимого, чтобы найти рекомендации. Чтобы не recommendMoviesзависеть от логики фильтрации, мы создадим новый класс ContentBasedFilterс вызываемым методом getRecommendations. В этом методе вы могли бы реализовать сложную фильтрацию, которая просматривает соответствующие данные, такие как история просмотров, рейтинг соответствия пользователей и т. Д. Помните об этих идеях, когда вы продолжите расширять этот проект после урока.
А пока мы жестко запрограммируем getRecommendations возврат тех же трех фильмов.
Теперь мы можем использовать методы ContentBasedFilterкласса в RecommenderImplementationклассе. Замените предыдущую жестко запрограммированную реализацию recommendMoviesследующей реализацией на основе зависимостей.
Наконец, мы добавим toStringметод к mainметоду, чтобы сделать массив String доступным для чтения в качестве вывода.