Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
Java-программистам необходим фреймворк Spring. Этот невероятный инструмент универсален: вы можете разрабатывать как приложения для малого бизнеса, так и микросервисервисные архитектуры промышленного масштаба. Освоить Spring не так-то просто, но первый шаг сделать легко! Книга предназначена для Java-разработчиков, желающих создавать приложения на основе Spring. Информативные иллюстрации, понятные примеры, а также ясное и живое изложение Лауренциу Спилкэ позволят быстро овладеть необходимыми навыками. Вы научитесь планировать, разрабатывать и тестировать приложения. Благодаря акценту на наиболее важных функциях разберетесь в богатой экосистеме фреймворка Spring.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 401
Veröffentlichungsjahr: 2023
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Переводчик Е. Сандицкая (Полонская)
Литературный редактор Е. Быковская
Лауренциу Спилкэ
Spring быстро. — СПб.: Питер, 2022.
ISBN 978-5-4461-1969-1
© ООО Издательство "Питер", 2022
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Появившись в начале 2000-х годов, фреймворк Spring быстро превзошел своего конкурента EJB по простоте модели программирования, разнообразию функций и интегрированным сторонним библиотекам. Со временем Spring превратился в наиболее обширный и зрелый из существующих фреймворков для разработки, доступных на каком-либо языке программирования. Главный конкурент Spring сошел с дистанции, когда компания Oracle прекратила работу над платформой Java EE 8 и сообщество взяло ее поддержку на себя, переименовав в Jakarta EE.
Согласно последним обзорам, фреймворк Spring является основой более половины Java-приложений. Это огромная кодовая база, поэтому изучить Spring критически важно, ведь в своем профессиональном развитии вы неизбежно столкнетесь с данной технологией. Я занимался созданием приложений на основе Spring в течение 15 лет, и сегодня практически все обучаемые мной разработчики из сотен компаний используют эту экосистему.
Реальность такова, что, несмотря на всю популярность Spring, довольно трудно найти качественные вводные материалы по данному фреймворку. Его справочная документация насчитывает несколько тысяч страниц. Там описываются всевозможные тонкости и детали, которые могут пригодиться в очень специфических сценариях, но начинающему разработчику нужно не это. Онлайновые видеоуроки и учебники не особенно привлекательны для изучающих фреймворк, а в немногих книгах по основам Spring зачастую уделяется слишком много места обсуждению тем, которые, как оказалось, не имеют отношения к современным проблемам разработки приложений. Однако в книге Лауренциу Спилкэ вы едва ли найдете что-нибудь лишнее: все изложенные здесь концепции постоянно встречаются в разработке любых Spring-приложений.
Данное издание аккуратно выведет вас на уровень, достаточный для быстрого достижения успеха в проекте, основанном на фреймворке Spring. Мой собственный опыт подготовки тысяч сотрудников показывает, что сейчас подавляющее большинство программистов, работающих на Spring, не понимают суть фреймворка так четко, как ее объясняет данная книга. Более того, разработчикам неизвестны многие подводные камни, о которых предупреждает книга. Считаю, что она обязательна к прочтению для любого разработчика, начинающего свой первый проект на Spring.
Та предусмотрительность, с которой Лауренциу предугадывает возможные вопросы читателей, доказывает его обширный опыт в преподавании Spring. Автор обращается к читателю тепло, по-дружески, благодаря чему изучать книгу легко и приятно. Издание имеет ясную, четкую структуру: я восхищаюсь тем, как сложные темы постепенно раскрываются и объясняются в основном материале, а затем повторяются в последующих главах.
Книга прекрасна также тем, что рассказывает читателю о фундаментальных проблемах преемственности проектов, в которых используется фреймворк Spring. Я обнаружил, что в экосистеме, построенной на Spring Boot, бывает очень полезно заглянуть за кулисы. А еще автор знакомит читателя с такими технологиями последнего поколения, как Feign-клиенты и даже реактивное программирование.
Желаю вам приятного чтения. Никогда не бойтесь закопаться в код, который кажется вам слишком сложным!
Виктор Рента,
Java-рыцарь, тренер и консультант
Делиться знаниями и создавать учебные материалы — мое хобби. Я не только разработчик программного обеспечения, но и преподаватель. С 2009 года я обучил Java тысячи разработчиков с разным уровнем опыта, от студентов университета до маститых специалистов из крупных корпораций. За последние несколько лет я пришел к выводу, что новички обязательно должны освоить Spring. Современные приложения больше не пишутся на чистых языках программирования — почти все они основаны на фреймворках. А поскольку в настоящее время Spring является самым популярным фреймворком для написания Java-приложений, именно с ним разработчику стоит познакомиться в первую очередь.
Преподавая Spring начинающим, я столкнулся с тем, что его все еще считают фреймворком, который следует изучать, уже имея некоторый опыт программирования. Есть множество учебных материалов, книг и статей на эту тему, однако мои студенты постоянно жаловались, что все эти материалы слишком сложны для них. Я понял, что проблема не в том, что существующие пособия недостаточно хороши, а в том, что среди них нет учебников для изучающих Spring с нуля. Поэтому я решил написать книгу, в которой не предполагается, что вы знакомитесь со Spring, уже имея некоторый опыт, — напротив, она рассчитана на читателя с минимальными фундаментальными знаниями.
Технологии меняются быстро. Но меняются не только они. Необходимо также улучшать способы обучения этим технологиям. Несколько лет назад можно было изучить основы языка программирования и стать разработчиком, не имея никакого представления о фреймворках. Однако сейчас ситуация изменилась. Овладевание лишь тонкостями языка программирования больше не гарантия того, что вы быстро получите навыки, необходимые для работы в команде программистов. Сегодня я рекомендую разработчикам, освоив начальную базу, переходить к изучению одного из фреймворков для построения приложений. Spring, по моему мнению, — наилучший вариант, с которого следует начать. Понимание основ Spring откроет вам двери к другим технологиям. Таким образом вместо устаревшего линейного обучения вы получите нечто похожее на дерево, где каждая ветвь — это новый фреймворк, который вы будете осваивать параллельно с другими.
Я структурировал книгу так, чтобы вы захотели начать обучение Spring с ней. Постепенно, шаг за шагом, издание снабдит вас всеми необходимыми теоретическими знаниями и примерами, в которых описываемые темы будут продемонстрированы на практике. Надеюсь, данная книга принесет вам пользу, поможет быстро получить знания по Spring и откроет двери к дальнейшему изучению фреймворков.
Эта книга не появилась бы, если бы мне не помогали многие умные, профессиональные и доброжелательные люди.
Прежде всего, огромное спасибо моей жене Даниэле, которая всегда была рядом. Ее ценные замечания, бесконечная поддержка и ободрение невероятно мне помогли.
Также хочу выразить признательность и особо поблагодарить всех коллег и друзей, которые помогали мне ценными советами, начиная с самого первого списка глав и заявки в редакцию.
Большое спасибо всей команде издательского дома Manning за помощь в претворении моих идей в живую книгу. Особенно я признателен Марине Майклс, Алу Шереру и Джин-Франсуазе Морин за невероятную поддержку и профессионализм. Ваши советы оказали огромное влияние на мою книгу.
Хочу поблагодарить мою подругу Иоану Гез за рисунки, которые она сделала для этой книги. Она превратила мои мысли в забавные картинки.
Хочу также выразить признательность всем рецензентам, которые на каждом этапе создания книги оставляли невероятно полезные отзывы: Алену Ломпо, Александру Карпенко, Андреа-Карло Гранате, Андреа Пачолле, Андре-Дамиану Сакко, Эндрю Освальду, Бобби Лину, Бонни Малец, Кристиану Крейцер-Беку, Дэниэлу Карлу, Дэвиду-Лайелу Орпену, Деандре Рашону, Харинату Кунтамуккале, Ховарду Уоллу, Жерому Батону, Джиму Уэлшу, Жуану-Мигелю-Пиресу Диасу, Лучиану Энаке, Мэтту Д., Мэтью Грину, Микаэлю Бистрему, Младену Кнежичу, Натану Б. Крокеру, Пьеру-Мишелю Анселю, Раджешу Моханану, Рикардо Ди Паскуале, Суните Чоудхури, Тану Ви и Зохебу Айнапуру. Благодаря вам эта книга стала гораздо лучше.
Наконец, особая благодарность моим друзьям — Марии Китцу, Андреа Тудосе, Флорин Чукулеску и Даниэле Илеана за советы, которые они давали мне все время, пока я писал эту книгу.
Раз уж вы открыли эту книгу, предположу, что вы являетесь разработчиком программного обеспечения в экосистеме Java и решили, что вам стоит познакомиться со Spring. С помощью данного издания вы изучите основы Spring, даже если до сих пор ничего не знали о фреймворках в целом и, разумеется, о Spring в частности.
Сначала вы узнаете, что вообще такое фреймворк, а затем постепенно на соответствующих примерах изучите основы Spring. Вы не только научитесь использовать компоненты и возможности фреймворка, но и познакомитесь с основными принципами, на базе которых эти возможности реализованы. Понимание того, что делает фреймворк, когда вы применяете тот или иной компонент, поможет вам проектировать более качественные приложения и быстрее справляться с проблемами.
Когда вы дочитаете это издание, вы будете обладать такими крайне важными при разработке приложений навыками, как:
• настройка и использование контекста Spring и внедрение зависимостей в Spring;
• разработка и использование аспектов;
• реализация веб-приложений;
• реализация обмена данными между приложениями;
• сохранение данных;
• тестирование реализаций.
Эта книга будет полезной:
• в повседневной работе с приложениями, использующими Spring;
• для успешного прохождения технического собеседования на позицию Java-разработчика;
• для получения сертификата по Spring.
И хотя подготовить вас к сертификации по Spring не является главной целью настоящего издания, все же полагаю, что его обязательно нужно прочесть, прежде чем вы углубитесь в детали, которые обычно требуются для сертификационного экзамена.
Книга предназначена для тех разработчиков, которые владеют основами объектно-ориентированного программирования и концепциями Java и хотят изучить Spring с нуля либо освежить базовые знания по нему. От вас не требуется знакомство с каким-либо фреймворком, но нужно знать основы Java, поскольку именно этот язык используется в примерах, приводимых в книге.
Spring является одной из самых распространенных технологий, применяемых в Java-приложениях. В будущем, скорее всего, данный фреймворк станет использоваться еще интенсивнее. Поэтому современный Java-разработчик просто обязан изучить Spring. Освоив то, чему я собираюсь научить вас в этой книге, вы повысите свою квалификацию, получите понимание основ Spring, овладеете навыками, необходимыми для успешного прохождения интервью на позицию Java-разработчика, а также сможете создавать приложения с использованием технологий Spring. Это издание также откроет для вас возможность дальнейшего изучения более сложных нюансов Spring.
Данная книга состоит из 15 глав, разделенных на две части. В первой части мы начнем обсуждение с простых примеров, где я покажу вам, как сообщить Spring о существовании вашего приложения. Затем мы выполним несколько примеров, чтобы вам стало понятно, на чем базируется любое реальное Spring-приложение. Закончив с основами Spring Core, мы перейдем к обсуждению Spring Data и Spring Boot.
Начиная с главы 2, теоретические вопросы будут сопровождаться примерами, в которых мы будем применять полученные знания. Я буду объяснять код этих примеров фрагмент за фрагментом. Советую выполнять их по мере чтения книги — так вы сможете сравнить свои результаты с тем, что получилось у меня.
Как показано на рис. 1, я выстроил главы в определенном порядке. В главах с 2-й по 5-ю, где обсуждается контекст Spring, вы найдете преимущественно теоретические примеры. Мало знакомому или вовсе не знакомому со Spring читателю необходимо начинать именно с них. Не беспокойтесь, я опишу основы самым простым из возможных способов. Затем наши примеры и обсуждения будут постепенно усложняться и начнут соответствовать реальному коду промышленного качества.
Рис. 1. Если вы ничего или почти ничего не знаете о Spring, то лучше всего при изучении данной книги начать с первой главы и дальше читать все подряд
Если вы уже хорошо знакомы с контекстом Spring и Spring AOP, можете пропустить часть I и сразу перейти к части II — «Реализация» (главы 7–15), как показано на рис. 2.
Рис. 2. Если вы уже знакомы с основами фреймворка Spring, умеете использовать контекст Spring и знаете аспекты проектирования, можете начать с части II, где мы применим возможности Spring для построения сценариев зеркального отображения приложений, с которыми вы столкнетесь в реальных системах
К тому моменту, как вы дочитаете настоящую книгу, вы освоите множество навыков профессиональной разработки приложений. Вы узнаете, как, используя наиболее распространенные современные технологии, подключиться к базе данных и как организовать коммуникацию между приложениями. В конце издания мы рассмотрим критически важную тему: тестирование. Я буду постоянно вставлять в текст истории из собственной практики и заметки с полезными советами.
Следует помнить, что Spring — это целая вселенная. Так что, прочитав только одну книгу, вы не узнаете всего. Данное издание станет для вас лишь началом знакомства с этим фреймворком; благодаря ему вы освоите фундаментальные навыки использования важнейших компонентов Spring. На протяжении всей книги, там, где это уместно, я буду давать ссылки на другие ресурсы и книги, в которых рассматриваемые темы описываются более подробно. Настоятельно рекомендую вам ознакомиться с этими дополнительными ресурсами и книгами.
В этой книге представлено около 70 проектов, над которыми мы будем работать в главах 2–14. Разбирая конкретный пример, я буду указывать название проекта, в котором этот пример реализован. Советую писать код самостоятельно и использовать проекты в книге только для сравнения ваших решений с моими. Такой подход позволит вам глубже понять изучаемые концепции.
Примеры проектов, рассмотренных в книге, можно скачать по адресу https://manning-content.s3.amazonaws.com/download/a/32357a2-2420-4c0f-be67-645246ae0d94/code.zip.
Все рассмотренные проекты собирались с помощью Maven, чтобы упростить их импорт в любую IDE. Я писал проекты в IntelliJ IDEA, но вы можете запускать их из Eclipse, Netbeans или любой другой среды, на ваш выбор. Обзор рекомендованных инструментов представлен в приложении Е.
В данной книге есть много примеров исходного кода, как в виде пронумерованных листингов, так и прямо в тексте. В обоих случаях исходный код оформляется такиммоношириннымшрифтом, чтобы можно было отличить его от остального текста. Иногда используются выделенияжирнымшрифтом, чтобы показать, что код изменился по сравнению с предыдущими этапами (например, когда в существующую строку добавлялся новый функционал). Во многих случаях первоначальный вид кода был изменен — вставлены разрывы строк и изменены отступы, чтобы код поместился по ширине книжной страницы. Изредка и этого было недостаточно, и тогда в листинги вставлялись символы продолжения строки (). Кроме того, если код описан в тексте, то из него часто удалялись комментарии. Многие листинги сопровождаются аннотациями, в которых подчеркиваются основные концепции.
Лауренциу Спилкэ — глава отдела разработки и тренер в компании Endava, где он руководит разработкой проектов для финансового рынка Европы, США и Азии. Его опыт работы насчитывает более десяти лет. По мнению Лауренциу, важно не только создавать высококачественное программное обеспечение, но также делиться знаниями и помогать другим повышать свою квалификацию. Руководствуясь этими соображениями, Лауренциу создал курсы по технологиям Java и сам преподает там, проводя презентации и мастер-классы. Его «Твиттер» — @laurspilca.
Рисунок на обложке книги называется «Женщина из Аяччо на Корсике». Это иллюстрация из коллекции «Костюмы народов мира» Жака Грассе де Сен-Совера (1757–1810), изданной во Франции в 1797 году. Каждая иллюстрация тщательно прорисована и раскрашена вручную. Богатство коллекции Грассе де Сен-Совера живо напоминает нам о том, как далеки были друг от друга культуры разных городов и регионов всего 200 лет назад. Изолированные, люди говорили на разных диалектах и языках. Встретив человека на городской улице или в сельской местности, мы бы легко поняли, откуда он родом, чем занимается и каков его достаток, всего лишь взглянув на его одежду.
С тех пор наша манера одеваться изменилась. Сегодня региональные различия, столь явные в прошлом, стерлись. Сейчас вы едва ли определите по одежде жителей разных континентов, не говоря уже о городах, регионах и странах. Похоже на то, что мы, поступившись культурным разнообразием, получили взамен более многоликую жизнь — разумеется, это касается в том числе и более многогранной и быстро меняющейся жизни технологий.
Сейчас, когда бывает трудно внешне отличить одну книгу о компьютерах от другой, мы поощряем изобретательность и инициативу компьютерного бизнеса, размещая на обложках своих книг рисунки Грассе де Сен-Совера и показывая, сколь сильно различалась жизнь в разных странах всего пару сотен лет назад.
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
• Что такое фреймворк.
• Когда нужно, а когда не следует использовать фреймворки.
• Что такое фреймворк Spring.
• Как применять Spring в реальных условиях.
Фреймворк Spring (или просто Spring) — это прикладной фреймворк, который является частью экосистемы Java. Прикладной фреймворк — это пакет типичных функций программного обеспечения, образующих базовую структуру для разработки приложения. Прикладной фреймворк позволяет тратить меньше усилий при написании приложения, так как не приходится создавать весь код программы с нуля.
В настоящее время Spring используется для написания самых разных программ, от крупных серверных решений до средств автоматизации тестирования. Согласно многочисленным отчетам об исследованиях в области Java-технологий, таких как JRebel 2020 года или JAXEnter, Spring в настоящее время является наиболее востребованным фреймворком.
Spring популярен: разработчики стали чаще использовать его не только с Java, но и с другими JVM-языками. В последние несколько лет наблюдается впечатляющее увеличение числа разработчиков, применяющих Spring с Kotlin (еще одним популярным языком семейства JVM). В этой книге мы сосредоточимся на основах Spring: я познакомлю вас с важнейшими аспектами его использования на примерах реальных приложений. Чтобы вам было удобнее и вы могли лучше сфокусироваться на Spring, я буду использовать только примеры на Java. В издании вы изучите и отработаете на практике такие основные приемы, как подключение к базе данных, установка соединения между приложениями, обеспечение безопасности и тестирование приложений.
Прежде чем перейти к следующим главам и углубиться в технические детали, поговорим о фреймворке Spring в целом и о том, где его стоит применять. Почему Spring столь популярен и когда им следует пользоваться?
В данной главе на примере Spring мы подробно рассмотрим, что такое фреймворк вообще. В разделе 1.1 мы обсудим преимущества использования фреймворков. В разделе 1.2 вы познакомитесь с экосистемой Spring и с теми ее компонентами, которые понадобятся для начала работы с ней. Затем я расскажу вам о возможных областях применения фреймворка Spring и о реальных сценариях из практики, раскрытых, в частности, в разделе 1.3. В разделе 1.4 мы обсудим случаи, когда использование фреймворка может оказаться неудачным решением. Все эти моменты следует прояснить прежде, чем вы начнете использовать Spring, — чтобы потом не забивать гвозди микроскопом.
Возможно, в зависимости от ваших исходных знаний, эта глава покажется вам сложной. В ней представлены понятия, с которыми вы, вероятно, еще не знакомы — и это может вызывать беспокойство. Но не волнуйтесь — даже если вы пока какие-то моменты не поймете, в процессе изучения книги они прояснятся. Иногда в процессе изложения я буду ссылаться на что-то описанное в предыдущих главах. Я буду так делать, поскольку изучение такого фреймворка, как Spring, не проходит линейно. Иногда придется подождать, пока соберется еще несколько кусочков пазла и станет видна вся картина. Но в итоге вы получите ясное представление о Spring и приобретете ценные навыки, необходимые для профессиональной разработки приложений.
Чтобы у вас появилось желание что-то использовать, вам нужно знать, чем это «что-то» может быть вам полезно. Это касается и Spring. В данном разделе мы поговорим о фреймворках. Что это такое? Как и зачем появилась концепция фреймворков? Я познакомлю вас с этими важными моментами, для чего поделюсь собственными накопленными знаниями и покажу, как использовать различные фреймворки, включая Spring, при решении практических задач.
Прикладной фреймворк — это набор функционала, на базе которого строятся приложения. Прикладной фреймворк предоставляет широкий набор инструментов и функций, которые можно применять в разработке. Вы не обязаны использовать их все. В зависимости от требований, предъявляемых к разрабатываемому приложению, вы будете выбирать ту часть фреймворка, которая вам нужна.
В отношении прикладных фреймворков мне нравится такая аналогия. Приходилось ли вам покупать мебель, скажем, в «Икее»? Предположим, вы решили приобрести платяной шкаф. Но вы получите не готовый шкаф, а набор деталей для его сборки и инструкцию по сборке. А теперь представьте, что вы заказали шкаф, но вместо необходимых частей вам выдали вообще все, из чего можно собрать любую мебель: стол, шкаф и т.п. Если вам нужен только шкаф, то придется найти в этой куче нужное и собрать его. Именно так работает прикладной фреймворк: он предлагает все возможные компоненты программного обеспечения, которые могут понадобиться при создании любого приложения. Вам необходимо знать, какие функции выбрать и как их собрать, чтобы получить правильный результат (рис. 1.1).
Рис. 1.1. Дэвид заказал шкаф в магазине «Сделай сам». Но магазин (фреймворк) доставил Дэвиду (программисту) не только те детали (компоненты программного обеспечения), которые нужны для сборки его шкафа (приложения), а вообще все возможные детали, которые могут понадобиться при сборке любого шкафа. И Дэвиду (программисту) придется самому решать, какие детали (программные компоненты) необходимы и как их собрать, чтобы получить желаемый результат (приложение)
Концепция фреймворка не нова. На протяжении всей истории разработки ПО программисты замечали, что многие фрагменты написанного ими кода можно использовать повторно в других приложениях. Поначалу, когда приложений было мало, каждое из них было уникально и писалось с нуля на том или ином языке программирования. По мере того как область применения программного обеспечения расширялась и на рынке появлялось все больше продуктов, стало еще заметнее, как много приложений имеют сходные требования. Вот некоторые из них:
• в каждом приложении предусмотрены уведомления при ошибках входа, предупреждения и информационные сообщения;
• в большинстве приложений для обработки изменений данных используются транзакции. Транзакции являются важным механизмом, который обеспечивает целостность данных. Подробнее мы рассмотрим эту тему в главе 13;
• в большинстве приложений применяются механизмы защиты от одних и тех же распространенных уязвимостей;
• в большинстве приложений используются одни и те же механизмы обмена данными с другими приложениями;
• в большинстве приложений есть одни и те же механизмы повышения производительности, такие как кеширование и сжатие данных.
Данный список можно продолжать. В сущности, код бизнес-логики, реализованной в приложении, значительно меньше, чем вся эта внутренняя начинка (которую еще называют «сантехникой»).
Говоря о «коде бизнес-логики», я имею в виду код, реализующий бизнес-требования приложения. Именно он реагирует на ожидания пользователя от продукта. Например, пользователю нужно, чтобы при щелчке кнопкой мыши на определенной ссылке был сформирован отчет. Эту функциональность реализует часть кода создаваемого вами приложения — и именно эту часть разработчики называют кодом бизнес-логики. Однако любое приложение делает и ряд других вещей: обеспечивает безопасность, журналирование, целостность данных и т.п. (рис. 1.2).
Рис. 1.2. Взгляду пользователя доступна только верхушка айсберга. Пользователи видят главным образом результат работы бизнес-логики. Но это лишь малая доля того, что представляет собой полный функционал приложения. Подобно айсбергу, большая часть которого находится под водой и скрыта от глаз, мы не видим основную часть кода корпоративного приложения, поскольку она выполняется посредством зависимостей
Более того, именно бизнес-логика отличает одно приложение от другого с точки зрения функционала.
Если взять два приложения разных типов — например, систему поиска попутчиков и социальную сеть, — то увидим, что сценарии использования у них разные.
Примечание
Сценарий использования (use case) — это причина, по которой человек использует приложение. Например, в приложении поиска попутчиков сценарием использования будет «найти машину». А для приложения доставки еды — «заказать пиццу».
Вы можете выполнять различные действия, но в обоих случаях они будут требовать сохранения данных, их передачи, журналирования, настройки параметров безопасности, возможно, кеширования и т.п. Функционал, не относящийся к бизнес-логике, может многократно внедряться в разные приложения. Имеет ли смысл каждый раз заново его переписывать? Разумеется, нет:
• ведь, используя готовые модули вместо их разработки с нуля, вы не тратите время и деньги зря;
• в готовом решении, применяемом во многих приложениях, вероятность ошибок меньше, так как его уже протестировали другие люди;
• поскольку многие разработчики уже освоили этот функционал, вы можете пользоваться советами сообщества. Если бы вы реализовали собственный код, в нем разбиралось бы гораздо меньше людей.
История перехода
Одним из первых продуктов, над которыми я работал, была огромная система, написанная на Java. Она состояла из нескольких приложений, построенных на базе сервера с устаревшей архитектурой. Все они были написаны с нуля на Java SE. Разработка приложения на данном языке началась 25 лет назад — главным образом поэтому оно было таким, каким было. На момент его создания никто не мог представить, до каких размеров оно однажды дорастет. Тогда еще не существовало более совершенных концепций системной архитектуры; из-за низкой скорости интернет-соединений все, как правило, реализовывалось отдельно в рамках каждой системы и работало по-разному.
Но время шло — и спустя годы приложение стало похоже на большой ком грязи. По ряду уважительных причин (которые я не буду здесь упоминать) команда разработчиков решила, что необходимо перейти на более современную архитектуру. Эти изменения подразумевали в первую очередь очистку кода. И одним из первых шагов было использование фреймворка. Мы выбрали Spring. На то время у нас был Java EE (сейчас это Jakarta EE), но большинство участников проекта решили, что лучше перейти на Spring, так как этот фреймворк является более простой альтернативой, которую легче реализовать и проще поддерживать.
Переход был не из простых. Вместе с парой коллег, каждый из которых был экспертом в своей области, а также хорошо разбирался в работе самого приложения, мы потратили на это преобразование много сил.
Но результат был потрясающим! Мы удалили более 40 % строк кода. Именно в этот момент я впервые понял, какое серьезное влияние может оказать использование фреймворка.
Примечание
Выбор и использование фреймворка зависит от конструкции и архитектуры приложения. Изучая фреймворк Spring, вы поймете, что имеет смысл исследовать также и эти аспекты. В приложении А вы найдете описание архитектур программного обеспечения и ссылки на отличные ресурсы на тот случай, если захотите углубиться в данную тему.
Рассмотрим Spring и связанные с ним проекты Spring Boot и Spring Data. В книге вы узнаете о них все и вдобавок получите полезные ссылки. На практике часто используют несколько фреймворков одновременно, каждый из которых помогает ускорить разработку определенной части приложения.
Мы называем Spring фреймворком, но в действительности он гораздо сложнее. Spring — это целая экосистема фреймворков. Как правило, когда разработчики упоминают фреймворк Spring, они имеют в виду часть программного функционала, которая включает в себя следующее.
1. Spring Core — фундаментальная часть Spring, в которой реализован его базовый функционал. Одной из этих функций является контекст Spring. Как будет подробно описано в главе 2, контекст Spring — это фундаментальная функциональная возможность, благодаря которой Spring может управлять экземплярами приложения. Также частью функционала Spring Core являются аспекты Spring. С ними Spring может перехватывать определенные в приложении методы и манипулировать ими (мы подробно рассмотрим аспекты в главе 6). Еще один компонент, который вы обнаружите в составе Spring Core, — это Spring Expression Language (SpEL). Он позволяет описывать конфигурации Spring с помощью специального языка. Наверняка для вас все это новые понятия — я не ожидаю, что вам приходилось слышать о них ранее. Но вскоре вы поймете, что в состав Spring Core входят механизмы, позволяющие интегрировать Spring в ваше приложение.
2. Spring MVC (model-view-controller, «модель — представление — контроллер»). Эта часть фреймворка Spring позволяет создавать веб-приложения, обрабатывающие HTTP-запросы. Мы будем использовать Spring MVC, начиная с главы 7.
3. Spring Data Access — еще одна базовая часть Spring. Она предоставляет основные инструменты для соединения с базами данных SQL, что позволяет реализовать уровень доступа к данным в приложении. Мы будем использовать Spring Data Access, начиная с главы 13.
4. Spring Testing. Эта часть фреймворка включает в себя инструменты, позволяющие писать тесты для Spring-приложения. Мы рассмотрим эту тему в главе 15.
Для начала вы можете представить фреймворк Spring в виде планетной системы, в которой Spring Core играет роль центральной звезды и притягивает к себе остальные части фреймворка (рис. 1.3).
Рис. 1.3. Фреймворк Spring можно представить в виде планетной системы, в центре которой находится Spring Core. Модули программного обеспечения играют роль планет, которые вращаются вокруг «звезды» Spring Core и удерживаются ее гравитационным полем
Spring Core — это та часть фреймворка Spring, которая обеспечивает фундаментальные механизмы его интеграции в приложение. Spring работает по принципу инверсии управления (inversion of control, IoC): вместо того чтобы приложение само контролировало свое выполнение, управление передается некоторому другому программному обеспечению — в данном случае фреймворку Spring. Посредством системы настроек мы предоставляем фреймворку инструкции о том, как распоряжаться написанным нами кодом, что и определяет логику работы приложения. Именно это и подразумевается под «инверсией» в аббревиатуре IoC: мы не позволяем приложению управлять собственным выполнением посредством его же кода или использовать зависимости. Вместо этого мы передаем фреймворку (зависимости) управление приложением и его кодом (рис. 1.4).
Примечание
В этом контексте «управление» означает такие действия, как «создание экземпляра» или «вызов метода». Фреймворк может создавать объекты классов, определенных в приложении. На основании написанных вами конфигураций Spring способен перехватывать выполнение метода и дополнять его различными функциями, к примеру регистрацией любой ошибки, которая может возникнуть в процессе выполнения этого метода.
Рис. 1.4. Инверсия управления: вместо того чтобы выполнять собственный код, в котором используется несколько зависимостей, в сценарии IoC приложение выполняется под управлением зависимости. В данном случае выполнением приложения управляет фреймворк Spring. Таким образом, Spring реализует сценарий выполнения IoC
Мы начнем изучение Spring со Spring Core, а изучение Spring Core — с функционала Spring IoC, который рассмотрим в главах 2–5. Контейнер IoC «склеивает» компоненты Spring между собой, а компоненты приложения — с фреймворком. Благодаря контейнеру IoC, который часто называют контекстом Spring, объекты становятся видимыми для Spring, и фреймворк может их использовать в соответствии с заданной вами конфигурацией.
В главе 6 мы продолжим рассматривать аспектно-ориентированное программирование (aspect-oriented programming, AOP) в Spring. Spring позволяет управлять экземплярами, помещенными в контроллер IoC, и, в частности, перехватывать методы, описывающие поведение этих экземпляров. Такая возможность называется аспектированием метода. Spring AOP — один из наиболее типичных способов взаимодействия фреймворка с приложением. Это свойство также делает Spring AOP одной из необходимейших частей фреймворка. В состав Spring Core входят также управление ресурсами, интернационализация (i18n), преобразование типов и SpEL. Все эти функции неоднократно встретятся нам в примерах на протяжении всей книги.
Для большинства приложений критически важно сохранять часть обрабатываемых данных. Работа с базами данных — фундаментальная часть проекта. В Spring для сохранения данных, как правило, применяется модуль Data Access. В нем используется, в частности, управление транзакциями, JDBC и интеграция с фреймворками, реализующими объектно-реляционную привязку (object-relational mapping, ORM), например, с Hibernate (если вы еще не знаете, что такое ORM-фреймворк, или ничего не слышали о Hibernate — ничего страшного; мы рассмотрим эти аспекты далее в книге). В главах 12–14 мы изучим все необходимое, чтобы вы смогли начать работать со Spring Data Access.
Большинство приложений, разрабатываемых на Spring, — это веб-приложения. Поэтому в экосистеме Spring вы обнаружите большой набор инструментов, позволяющих создавать всевозможные веб-приложения и веб-сервисы. С помощью Spring MVC можно писать их в виде обычных сервлетов, что, как правило, и делают для огромного количества современных продуктов. Мы рассмотрим использование Spring MVC более подробно в главе 7.
Модуль тестирования Spring включает в себя большой набор инструментов, которые мы будем использовать для написания модульных и интеграционных тестов. О тестировании написано немало страниц, но мы в главе 15 рассмотрим лишь то, что нужно для начала тестирования в Spring. Я также дам ссылки на ряд полезных ресурсов, которые стоит изучить, чтобы более детально разобраться в теме. Как показывает мой опыт, нельзя стать настоящим разработчиком, не освоив тестирования, так что вам необходимо в это вникнуть.
Экосистема Spring — это гораздо больше, чем просто функции, описанные выше. Она включает в себя множество других фреймворков, хорошо интегрированных между собой и образующих целую вселенную. Здесь вы найдете такие проекты, как Spring Data, Spring Security, Spring Cloud, Spring Batch, Spring Boot и т.д. При разработке вы можете использовать сразу несколько из них. Например, можно построить приложение на возможностях Spring Boot, Spring Security и Spring Data. В следующих главах мы будем работать над небольшими заданиями, в которых будем применять функционал различных проектов экосистемы Spring. Под проектом я подразумеваю независимо разработанную часть экосистемы Spring. Каждый из них — плод работы отдельной команды, продолжающей расширять его возможности. Все проекты имеют отдельное описание и свою ссылку на официальном веб-сайте Spring: https://Spring.io/projects.
Но я буду упоминать Spring Data и Spring Boot и за пределами вселенной Spring. Эти проекты часто используются в приложениях, так что важно изучить их сразу.
Проект Spring Data — это часть экосистемы Spring, которая позволяет легко подключаться к базам данных и использовать уровень доступа к данным, написав минимальное количество строк кода. Проект обращается как к SQL, так и к NoSQL-базам данных и имеет высокоуровневую обертку, которая упрощает работу с хранением данных.
Примечание
В нашем распоряжении есть модуль Spring Data Access, который является частью Spring Core, и Spring Data, который является независимым проектом экосистемы Spring. Spring Data Access обеспечивает реализацию фундаментальных средств доступа к данным, таких как механизм транзакций и инструменты JDBC. Spring Data упрощает доступ к базам данных и предлагает расширенный инструментарий, который делает разработку более понятной и обеспечивает возможность подключения приложения к разнообразным источникам данных. Мы рассмотрим эту тему подробнее в главе 14.
Проект Spring Boot — это часть экосистемы Spring, реализующая концепцию «соглашения важнее конфигурации». Главная идея этой концепции состоит в следующем. Вместо того чтобы описывать все параметры конфигурации в самом фреймворке, Spring Boot предлагает некую конфигурацию по умолчанию, которую можно изменять по мере необходимости. В результате, как правило, приходится писать меньше кода, поскольку вы следуете известным соглашениям и ваше приложение отличается от других лишь несколькими мелкими деталями.
Поэтому будет более эффективно не описывать заново всю конфигурацию в каждом новом приложении, а начать с некоторой конфигурации по умолчанию и изменить в ней лишь то, что отличается от общепринятого. Мы будем подробно рассматривать Spring Boot, начиная с главы 7.
Экосистема Spring огромна и включает в себя множество проектов. Некоторые из них будут встречаться чаще, чем другие; а некоторые, возможно, вам вообще не понадобятся, если только не придется разработать какое-то специфическое приложение. В этой книге будут упоминаться только те проекты, которые действительно необходимы на начальном этапе: Spring Core, Spring Data и Spring Boot. Полный список проектов экосистемы Spring вы найдете на официальном веб-сайте Spring: https://Spring.io/projects/.
Альтернативы Spring
Если углубиться в серьезное обсуждение альтернатив Spring, то некоторые читатели могут по ошибке посчитать их альтернативами всей экосистеме. Но аналоги есть у многих отдельных компонентов и проектов, входящих в экосистему Spring, — другие фреймворки и библиотеки, коммерческие или с открытым кодом.
Возьмем, к примеру, контейнер Spring IoC. Было время, когда разработчики очень ценили спецификацию Java EE. Обладая немного иной философией, Java EE (код которой в 2017 году был переработан, открыт и назван Jakarta EE — https://jakarta.ee/) предлагает такие спецификации, как Context and Dependency Injection (CDI) и Enterprise Java Beans (EJB). CDI и EJB можно использовать для управления контекстом экземпляров объектов и для реализации аспектов (которые в терминологии EE называются interceptors — «перехватчики»). Долгое время хорошим фреймворком для управления экземплярами объектов в контейнере был Google Guice (https://github.com/google/guice).
Для некоторых проектов удается найти одну или несколько альтернатив. Например, вместо Spring Security можно использовать Apache Shiro (https://shiro.Apache.org/). Или же вместо Spring MVC и технологий Spring можно построить веб-приложение на фреймворке Play (https://www.playframework.com/).
Из более новых проектов многообещающе выглядит Red Hat Quarkus (https://quarkus.io/). Quarkus был создан для внедрения облачных решений и сейчас быстро совершенствуется. Я не удивлюсь, если однажды он станет одним из ведущих проектов для разработки промышленных приложений в экосистеме Java.
Мой вам совет: всегда рассматривайте альтернативы. При разработке программного обеспечения необходимо держать глаза открытыми и никогда не верить в одно решение, «единственное и неповторимое». Вам постоянно будут встречаться сценарии, в которых одна технология работает лучше, чем другая.
Теперь, когда вы получили общее представление о Spring, вы понимаете, когда и как следует использовать данный фреймворк. Далее я приведу несколько примеров приложений, для которых Spring подошел бы идеально. Мне слишком часто встречались разработчики, которые считали, что фреймворки наподобие Spring подходят лишь для серверных приложений. Более того, я наблюдал тенденцию, когда область применения Spring сузилась еще сильнее — до серверных веб-приложений. Действительно, во многих случаях Spring используется именно в таком ключе, однако важно помнить, что этим возможности фреймворка не ограничиваются. Мне встречались команды, успешно использующие Spring для разработки самых разных приложений, таких как средства автоматизации тестирования и даже автономные десктопные решения.
Далее я покажу вам несколько реальных задач, которые на моих глазах были успешно решены с применением Spring. С одной стороны, это далеко не все возможные сценарии; с другой стороны, и в этих случаях Spring не всегда будет работать хорошо. Вспомните, о чем мы говорили в разделе 1.2: фреймворк не всегда удачный выбор. Но для следующих общих случаев Spring, как правило, отлично подходит.
1. Разработка серверных приложений.
2. Разработка средств автоматизации тестирования.
3. Разработка десктопных приложений.
4. Разработка мобильных приложений.
Серверное приложение — это часть системы, которая выполняется на стороне сервера и отвечает за управление данными и обслуживание запросов от клиентских приложений. Пользователи получают доступ к функционалу такого приложения через клиентские приложения, к которым пользователи, в свою очередь, обращаются напрямую. Далее клиентские приложения делают запросы серверному приложению для обработки данных пользователей. Серверное приложение может использовать базы данных для хранения информации или взаимодействовать различными способами с другими серверными приложениями.
В качестве примера вы легко можете вспомнить знакомое вам серверное приложение: это приложение, осуществляющее транзакции по банковским счетам. Пользователи получают доступ к своим счетам и управляют ими через мобильное или веб-приложение (интернет-банкинг). И мобильные, и веб-приложения являются клиентами серверного приложения. Для контроля пользовательских транзакций серверное приложение должно взаимодействовать с другими серверными решениями, а часть данных, которыми оно управляет, должна сохраняться в базе данных. На рис. 1.5 представлена визуализация архитектуры такой системы.
Рис. 1.5. Для управления данными серверное приложение различными способами взаимодействует с другими приложениями и подключается к базам данных. Как правило, серверные приложения достаточно сложны и требуют применения различных технологий. Фреймворки упрощают разработку серверных приложений, так как предоставляют инструментарий, позволяющий быстрее реализовать серверные решения
Примечание
Не страшно, если вы пока не понимаете всех деталей, изображенных на рис. 1.5. Я не ожидаю от вас знаний о том, что такое брокер сообщений; вы даже можете не знать, как организовать обмен данными между компонентами. Я лишь хочу, чтобы вы увидели, что в реальном мире такие системы бывают сложными, и поняли, что проекты экосистемы Spring созданы, чтобы позволить избежать этой сложности, насколько возможно.
Spring предлагает разработчику отличный инструментарий для создания серверных приложений. Наличие самых разных функций, которые обычно нужно включить в серверное приложение (от интеграции с другими приложениями до сохранения данных в различных базах данных), сильно упрощает жизнь. Неудивительно, что при создании подобных приложений разработчики часто используют Spring. Этот фреймворк содержит все необходимое для таких реализаций и отлично подходит для любых видов архитектуры. Возможности применения Spring для разработки серверных приложений показаны на рис. 1.6.
Рис. 1.6. Возможности применения Spring в серверных приложениях практически безграничны: от предоставления функций, которые могут вызываться другими приложениями, до управления доступом к базе данных и от обеспечения безопасности приложения до управления интеграцией посредством сторонних брокеров сообщений
В наши дни для сквозного тестирования разрабатываемых систем часто используется автоматизированное тестирование. Автоматизация тестирования означает создание программного обеспечения, которое позволяет команде разработчиков убедиться, что поведение приложения соответствует ожидаемому. Команда может составить расписание автоматизированного тестирования таким образом, чтобы проверять приложение достаточно часто и отправлять разработчикам уведомления, если что-то пошло не так. Такая функциональность дает больше уверенности, что создатели вовремя получат сообщение, если при разработке нового функционала они что-то сломают в уже существующих опциях приложения.
В случае небольших систем можно обойтись тестированием вручную, однако выполнение тестовых сценариев всегда полезно автоматизировать. В случае более сложных систем протестировать все потоки вручную в принципе невозможно. Поскольку потоков очень много, выполнение этой задачи заняло бы внушительное количество времени и слишком много сил.
На практике самым эффективным решением оказывается организация отдельной команды разработчиков, которая создает приложение, отвечающее за валидацию всех потоков тестируемой системы. Когда в систему добавляют новый функционал, тестовое приложение также дополняется с учетом нововведений, и разработчики используют его, чтобы убедиться, что все остальное по-прежнему работает, как должно.
В итоге разработчики используют средство интеграции, с помощью которого составляют расписание регулярного выполнения приложения, чтобы оперативно получать обратную связь о происходящих изменениях (рис. 1.7).
Рис. 1.7. Разработчики развертывают тестовое приложение в тестовой среде. Инструмент непрерывной интеграции наподобие Jenkins постоянно выполняет приложение и отправляет уведомления разработчикам. Таким образом, разработчики всегда в курсе состояния системы и немедленно узнают, если что-нибудь сломается в процессе разработки
Подобные приложения бывают не менее сложны, чем серверные. Чтобы проверить все рабочие потоки, приложение должно взаимодействовать со всеми компонентами системы и даже с базами данных. Иногда оно имитирует внешние зависимости, чтобы создать видимость разных внешних сценариев. Для написания тестовых сценариев разработчики используют фреймворки Selenium, Cucumber, Gauge и др. Однако даже с ними приложение может получить несколько преимуществ от использования инструментария Spring. Например, с помощью контейнера Spring IoC появляется возможность управлять экземплярами объектов, чтобы получился код, более удобный в обслуживании. При необходимости валидации данных можно организовать подключение к базам данных с помощью Spring Data. Чтобы имитировать определенные сценарии, можно отправлять сообщения в очереди или топики системы брокеров или же использовать Spring просто для вызова конечных точек REST (рис. 1.8). (Напомню еще раз: ничего страшного, если это кажется вам слишком сложным; все прояснится по мере того, как вы будете дальше читать книгу.)
Рис. 1.8. Иногда приложению тестирования нужно подключаться к базам данных, соединяться с другими системами или тестируемой системой. Компоненты экосистемы Spring позволяют упростить реализацию данного функционала
В наши дни десктопные приложения создаются не так уж часто: их обязанности по взаимодействию с пользователем взяли на себя мобильные и веб-приложения. Однако десктопные приложения, хоть их и мало, по-прежнему существуют, и компоненты экосистемы Spring могут оказаться весьма полезными при разработке их функционала. В десктопном приложении можно с успехом использовать контейнер Spring IoC для управления экземплярами объектов. Так реализация приложения получается более прозрачной, и его удобнее поддерживать. А еще Spring можно использовать для включения различных функций, таких как коммуникация с серверным приложением и другими компонентами (вызов веб-сервисов или использование других технологий для удаленных соединений) или внедрение решений для кеширования.
Благодаря проекту Spring for Android (https://Spring.io/projects/Spring-android) сообщество Spring может помочь в разработке мобильных приложений. Даже если вам редко приходилось с ними сталкиваться, следует помнить о возможности использовать инструментарий Spring при создании продуктов для Android. Этот проект Spring включает в себя REST-клиент для Android и поддержку аутентификации для доступа к защищенным API.
Рассмотрим вопрос, почему иногда фреймворков следует избегать. Очень важно понимать, когда стоит использовать фреймворк, а когда от него лучше отказаться. Иногда применение инструмента, слишком сложного для конкретной задачи, может потребовать больше сил, чем если бы его не использовали в принципе, или вообще привести к неверному результату. Это все равно что резать хлеб бензопилой: конечно, вы можете попытаться — и у вас даже получится, но процесс выйдет труднее и затратнее, чем нарезка обычным ножом (а вместо нарезанного хлеба может получиться куча крошек). Мы рассмотрим несколько сценариев, в которых использование фреймворка не лучшая идея. А затем я поделюсь историей о том, как одной команде разработчиков, в которую входил и я, не удалось реализовать проект из-за того, что мы использовали фреймворк.
Оказывается, что на фреймворк, как и на все остальное в мире разработки программного обеспечения, нельзя полагаться во всех случаях жизни. В практике вам встретятся ситуации, когда данное решение окажется неподходящим. Или в целом фреймворк будет хорошим выбором, но не фреймворк Spring. В каком из следующих сценариев его не стоит использовать?
1. Требуется реализовать определенный функционал, который бы занимал как можно меньше места (под занимаемым местом я понимаю объем памяти, занятый файлами приложения).
2. Специфические требования по безопасности вынуждают вас писать весь код приложения самостоятельно, без использования каких-либо фреймворков с открытым кодом.
3. Необходимо сделать так много надстроек над фреймворком, что написанного кода получится меньше, если фреймворк не использовать вообще.
4. У вас уже есть работающее приложение; перестроив его на использование фреймворка, вы не получите никаких преимуществ.
Рассмотрим эти пункты подробнее.
Здесь я имею в виду ситуации, когда необходимо маленькое приложение. В современных системах сервисы все чаще доставляются в контейнерах. Вам, вероятно, приходилось слышать о таких контейнерах, как Docker, Kubernetes и подобных (если нет — не страшно).
В целом тема контейнеров выходит за рамки данной книги, поэтому единственное, что вам стоит сейчас знать: если приложение развертывается подобным образом, необходимо, чтобы его размер был как можно меньше. Контейнер подобен коробке, в которой находится приложение. Важнейший принцип развертывания приложений в контейнерах гласит: контейнеры должны уничтожаться и создаваться максимально быстро. И здесь огромное значение имеет размер приложения. Чем он меньше, тем больше секунд вы сэкономите при инициализации приложения. Впрочем, это не означает, что вообще нельзя использовать фреймворки для приложений, которые развертываются в контейнерах.
Однако для определенных приложений, которые и сами по себе, как правило, довольно малы, предпочтительнее ускорить инициализацию и сократить размер, чем добавлять зависимости от различных фреймворков. Это касается в том числе так называемых внесерверных функций. Внесерверные функции представляют собой крошечные приложения, которые развертываются в контейнерах. Как следует из названия, они выполняются вне сервера, и мы едва ли можем влиять на способ их развертывания. Эти приложения обязаны быть маленькими, и именно поэтому, в силу их специфики, при разработке следует по возможности избегать подключения фреймворков. Возможно, что вследствие их размера фреймворк в принципе не понадобится.
Во втором пункте списка я имел в виду специфические ситуации, когда в приложении нельзя использовать фреймворк вследствие требований по безопасности. Такие требования обычно предъявляются к приложениям, которые создаются для военных или правительственных организаций. Снова отмечу: это вовсе не означает, что задействование фреймворков запрещено для всех приложений, используемых правительством. Но для некоторых из них существуют ограничения. Вы спросите почему? Хорошо, предположим, что мы применили в подобном приложении фреймворк с открытым исходным кодом, такой как Spring. Если некто найдет в нем подходящую уязвимость, о которой станет известно, хакеры смогут использовать данную информацию, чтобы взломать приложение. Иногда правообладатели таких продуктов желают свести вероятность взлома их системы к нулю, насколько возможно. Поэтому иногда приходится даже переписывать функционал, вместо того чтобы брать готовый из сторонних источников.
Примечание
Но как же так? Ведь раньше я говорил, что использовать открытый фреймворк безопаснее, поскольку если в нем возникает уязвимость, то кто-нибудь обязательно ее заметит. Да, но если инвестировать в проект достаточно много времени и денег, то вы, скорее всего, и сами решите эту проблему. Как правило, фреймворк дешевле. Если нет особых противопоказаний, то лучше использовать фреймворк. Но бывают проекты, правообладатели которых всерьез хотят застраховаться от утечки информации.
Еще один случай, когда, возможно, стоит отказаться от использования фреймворка, — это когда приходится слишком сильно изменять его компоненты и в итоге с ним получается еще больше кода, чем без него. Как я уже отмечал в разделе 1.1, фреймворк предоставляет разработчику функционал, который в сочетании с подключенным к нему бизнес-кодом образует приложение. Эти компоненты, взятые из фреймворка в чистом виде, не всегда подходят идеально, их так или иначе приходится изменять. В целом модифицировать элементы фреймворка и способ их подключения, вместо того чтобы писать все с нуля, — обычная практика. Но если вы обнаружите, что изменений слишком много, — скорее всего, вы неудачно выбрали фреймворк (поищите другие варианты) или, возможно, вам вообще не стоило его использовать.
В последнем пункте списка я отметил, что попытка использовать фреймворк, чтобы заменить уже существующую рабочую часть приложения, может оказаться ошибочной. Иногда возникает соблазн применить вместо имеющейся архитектуры что-то новое. Появился новый популярный фреймворк, все его используют, так почему бы и нам не переделать наше приложение, чтобы оно тоже опиралось на этот фреймворк? Да, так можно поступить, но прежде необходимо тщательно проанализировать, что вы хотите получить, заменив то, что и так работает. В некоторых случаях, как в моей истории из раздела 1.1, действительно имеет смысл переработать приложение, чтобы оно опиралось на определенный фреймворк. Если это изменение принесет пользу — вперед! Среди возможных причин может быть то, что приложение станет более удобным в обслуживании, более производительным или более защищенным. Но если изменение не принесет пользы, если, может, оно даже станет причиной нестабильной работы приложения, то в итоге может оказаться, что вы потратили время и деньги на неверный результат. Позвольте рассказать вам историю из моего собственного опыта.
Ошибка, которую можно было избежать
Использование фреймворка не всегда удачный вариант, и мне пришлось дорого заплатить за это знание. Много лет назад мы разрабатывали серверную часть веб-приложения. Времени подвластно все, включая архитектуру программного обеспечения. В приложении использовалось прямое подключение к базе данных Oracle посредством JDBC, и код выглядел весьма скверно. Везде, где в приложении требовалось выполнить запрос к базе данных, открывался оператор — и отправленный запрос часто занимал несколько строк. Если вы достаточно молоды, то, возможно, и не застали такую технологию. Тогда просто поверьте: это был длинный и уродливый код.
В те времена появилось несколько фреймворков, использующих другой способ работы с базой данных, и они становились все более популярными. Тогда я впервые услышал о Hibernate — ORM-фреймворке, который представлял таблицы базы данных и их взаимосвязи в виде объектов и зависимостей между ними. Это позволяло писать меньше кода и обеспечивало более понятную функциональность. Однако при неправильном использовании фреймворк мог замедлить работу приложения, код становился менее интуитивным и даже могли возникать ошибки.
Приложение, над которым велась работа, нуждалось в изменениях. Мы были уверены, что у нас получилось бы улучшить этот уродливый JDBC-код. Мне казалось, что можно было хотя бы сократить число строк. Такое изменение сделало бы код значительно удобнее в обслуживании. Несколько разработчиков, в том числе и я, предложили использовать инструмент Spring под названием JdbcTemplate (вы познакомитесь с ним в главе 12). Но другие жестко настаивали на Hibernate. Он был весьма популярен, так почему бы им не воспользоваться? (Собственно, он до сих пор является таковым, и в главе 13 мы рассмотрим его интеграцию со Spring.) Я понимал, что адаптация кода под совершенно новую методологию будет непростой задачей. Более того, я не видел в этом смысла. Изменения также были сопряжены с повышенным риском возникновения ошибок.
К нашему счастью, мы начали переход с апробации идеи. После несколько месяцев усилий и стресса команда решила это прекратить.
Проанализировав имеющиеся варианты, мы в итоге выбрали реализацию с использованием JdbcTemplate. Нам удалось написать более ясный код, удалив множество лишних строк, и не пришлось использовать для этого какой-либо новый фреймворк.
Раз уж вы открыли эту книгу, то вы, скорее всего, являетесь разработчиком программного обеспечения для экосистем Java, который посчитал полезным изучить Spring. Цель этой книги — научить вас основам работы с данным фреймворком. Предполагается, что вы ничего не знаете о фреймворках в целом и о Spring в частности. Под термином Spring я понимаю не только ядро Spring, но и всю экосистему Spring.
После изучения данной книги вы научитесь делать следующее:
• использовать контекст Spring и создавать аспекты для объектов под управлением фреймворка;
• использовать технологию соединения Spring-приложения с базой данных и работать с сохраненными данными;
• организовывать обмен данными между приложениями с помощью реализованных в Spring интерфейсов REST API;
• строить простейшие приложения на основе концепции «соглашение важнее конфигурации»;
• использовать наилучшие технологии создания типичных классов Spring-приложений;
• тщательно тестировать ваши Spring-разработки.
• Прикладной фреймворк — это набор типичного программного функционала, фундамент для разработки приложения. Фреймворк играет роль скелета, на котором строится приложение.
• Фреймворк помогает создать более эффективный продукт, предоставляя функционал, который вы встраиваете в свою реализацию, а не разрабатываете самостоятельно.
• Использование фреймворка экономит время и уменьшает вероятность возникновения ошибок.