service spring что это
Русские Блоги
Различия между Spring @Component, @Service, @Repository, @Controller
Spring @Component, @Service, @Repository, @Controller разница
Spring @Component, @Service, @Repository и @Controller аннотации используются для сканирования указанного класса пути, зарегистрированного как bean-компонент в среде Spring.
Для всех этих заметок (стереотипов) технически основная цель одна и та же.
Spring автоматически сканирует и распознает все классы, помеченные как «@Component, @Service, @Repository, @Controller», и может использовать ApplicationContext для получения этих компонентов.
Для всех компонентов-прототипов @Component, @Service, @Repository и @Controller он основан наBeanNameGeneratorИмя бина назначения политики. То есть первая буква имени класса строчная.
Мы также можем предоставить наш выбор имени во время комментария, это будет высокий приоритет
Разница в том, как будто вы ищете различия на картинке ниже
Я не могу найти это. Если кто-то знает их разницу, пожалуйста, оставьте сообщение в блоге
2018 8 15 Отредактировано снова по прошествии полугода,
Следующие слова были сказаны весной
Spring 2.5 вводит дополнительные типичные аннотации: @Component ， @Service И @Controller 。 @Component Это общий стереотип любого компонента управления Spring. @Repository ， @Service И, и @Controller Здесь @Component Специализация более конкретных вариантов использования, например, на уровнях персистентности, обслуживания и представления соответственно.
Так что если вы используете @Component или @Service Выбор между уровнями обслуживания, @Service Очевидно, лучший выбор. Точно так же, как упомянуто выше, @Repository Он поддерживается как маркер для автоматического преобразования исключений в слое постоянства.
Хороший английский взгляд на это
Разница между @Component, @Repository, @Controller и @Service
Это общая аннотация стереотипа, указывающая, что этот класс является компонентом Spring.
Что особенного в @Component
Только сканирование @Component И не найдете @Controller ， @Service и @Repository 。
Сканируйте их, потому что они все аннотированы @Component 。
Просто посмотрите @Controller ， @Service и @Repository Определение примечаний:
Поэтому не стоит говорить @Controller ， @Service и @Repository Это особый тип @Component Комментарии.
Выберите их и зарегистрируйте их подклассы как бины, как если бы они были аннотированы @Component 。
Это показывает, что этот класс определяет хранилище данных.
Что такого особенного в @Repository?
В дополнение к указанию, что этоКонфигурация на основе аннотаций， @Repository Наша работа заключается в том, чтобы отлавливать специфичные для платформы исключения и отбрасывать их как одно из унифицированных непроверенных исключений Spring. Для этого мы предоставляем PersistenceExceptionTranslationPostProcessor Нам нужно добавить следующее в контексте приложения Spring:
Этот постпроцессор бина добавляет советник к любому аннотированному бину, @Repository Чтобы перехватить любое специфическое для платформы исключение, а затем повторно выдать его как одно из непроверенных исключений доступа к данным в Spring.
что @Controller Аннотации указывают роль конкретного типа контроллера питания. что @Controller Аннотации действуют как стереотипы аннотаций, что показывает его роль.
Что такого особенного в @Controller?
Мы не можем отключить эту аннотацию как любую другую @Service или @Repository Хотя они выглядят одинаково. Планировщик сканирует аннотированные классы @Controller И обнаружить один из них @RequestMapping Комментарии. Мы можем только принести @Controller Используйте на аннотированных классах @RequestMapping 。
@Services Сохраните бизнес-логику и вызовите методы на уровне хранилища.
Что особенного в @Service?
Помимо того факта, что он используется для указания на то, что он содержит бизнес-логику, эта заметка не имеет очевидных особенностей, но кто знает, весна может добавить некоторые дополнительные специальные функции в будущем.
Как и выше, вы можете добавить специальные функции весной @Service ， @Controller и @Repository В соответствии с их наслоениями.
Поэтому всегда полезно соблюдать соглашения и использовать их последовательно со слоями.
Spring: вопросы к собеседованию
Этот небольшой список вопросов даст вам понимание самых важных концепций Spring, а так же поможет подготовится к собеседованию
Если вы понимаете как работает Component Scan, то вы понимаете Spring
Однако, Spring ничего не знает об этих бинах, если он не знает где искать их. То, что скажет Spring где искать эти бины и называется Component Scan. В @ComponentScan вы указываете пакеты, которые должны сканироваться.
Spring будет искать бины не только в пакетах для сканирования, но и в их подпакетах.
@SpringBootApplication определяет автоматическое сканирование пакета, где находится класс Application
Всё будет в порядке, ваш код целиком находится в указанном пакете или его подпакетах.
Однако, если необходимый вам компонент находится в другом пакете, вы должны использовать дополнительно аннотацию @ComponentScan, где перечислите все дополнительные пакеты для сканирования
@Component и @ComponentScan предназначены для разных целей
@Component помечает класс в качестве кандидата для создания Spring бина.
@ComponentScan указывает где Spring искать классы, помеченные аннотацией @Component или его производной
В классах конфигурации Spring, @Bean используется для определения компонентов с кастомной логикой.
@Bean используется в конфигурационных классах Spring. Он используется для непосредственного создания бина.
Все они определяют бины Spring. Однако между ними всё же есть разница.
@Component — универсальный компонент
@Repository — компонент, который предназначен для хранения, извлечения и поиска. Как правило, используется для работы с базами данных.
@Service — фасад для некоторой бизнес логики
Если @Component является универсальным стереотипом для любого Spring компонента, то @Service в настоящее время является его псевдонимом. Однако, в официальной документации Spring рекомендуется использовать именно @Service для бизнес логики. Вполне возможно, что в будущих версиях фреймворка, для данного стереотипа добавится дополнительная семантика, и его бины станут обладать дополнительной логикой.
web.xml — Метаданные и конфигурация любого веб-приложения, совместимого с Java EE. Java EE стандарт для веб-приложений.
servlet.xml — файл конфигурации, специфичный для Spring Framework.
Предпочитаю аннотации, если кодовая база хорошо описывается такими элементами, как @Service, @Component, @Autowired
Однако когда дело доходит до конфигурации, у меня нет каких-либо предпочтений. Я бы оставил этот вопрос команде.
@Autowired может использоваться вместе с конструкторами, сеттерами или любым другими методами. Когда Spring находит @Autowired на методе, Spring автоматически вызовет этот метод, после создания экземпляра бина. В качестве аргументов, будут подобраны подходящие объекты из контекста Spring.
Сквозная Функциональность — функциональность, которая может потребоваться вам на нескольких различных уровнях — логирование, управление производительностью, безопасность и т.д.
АОП — один из подходов к реализации данной проблемы
IOC — инверсия управления. Вместо ручного внедрения зависимостей, фреймворк забирает ответственность за это.
ApplicationContext — реализация IOC спрингом.
Bean Factory — это базовая версия IOC контейнера
Application Context также включает дополнительные функции, которые обычно нужны для разработки корпоративных приложений
classPathXmlApplicationContext — если вы хотите инициализировать контекст Spring при помощи xml
annotationConfigApplicationContext — если вы хотите инициализировать контекст Spring при помощи конфигурационного класса java
Если все бины имеют одинаковый приоритет, мы всегда будем использовать @Qualifier
На мой взгляд это Functional Web Framework, Kotlin и и поддержка реактивного программирования.
Web Container и EJB Containers являются частью приложения/веб-сервера, таких как Tomcat, Websphere, Weblogic. Они добавляют свою дополнительную функциональность к ним. Java EE определяет контракт для веб-приложений, эти контейнеры являются реализацией этих контрактов.
Spring контейнер может являться частью любого приложения, которое вы делаете на java. Spring может работать внутри веб-контейнера, ejb контейнера или даже без них.
Тогда в application.properties добавим свойство
application.greeting: real
Воспользуемся данным решением:
Spring 5.0 и Spring Boot 2.0 поддерживают Java 8 и более поздней версии.
@RestController = @Controller + @ResponseBody
@RestController превращает помеченный класс в Spring-бин. Этот бин для конвертации входящих/исходящих данных использует Jackson message converter. Как правило целевые данные представлены в json или xml.
ResponseEntity необходим, только если мы хотим кастомизировать ответ, добавив к нему статус ответа. Во всех остальных случаях будем использовать @ResponseBody.
Стандартные HTTP коды статусов ответов, которые можно использовать.
200 — SUCCESS
201 — CREATED
404 — RESOURCE NOT FOUND
400 — BAD REQUEST
401 — UNAUTHORIZED
500 — SERVER ERROR
Для @ResponseBody единственные состояния статуса это SUCCESS(200), если всё ок и SERVER ERROR(500), если произошла какая-либо ошибка.
Допустим мы что-то создали и хотим отправить статус CREATED(201). В этом случае мы используем ResponseEntity.
Концептуально всё просто, фильтры сервлетов могут перехватывать только HTTPServlets. Listeners могут перехватывать специфические события. Как перехватить события которые относятся ни к тем не другим?
Фильтры и перехватчики делают по сути одно и тоже: они перехватывают какое-то событие, и делают что-то до или после.
Java EE использует термин Filter, Spring называет их Interceptors.
Именно здесь AOP используется в полную силу, благодаря чему возможно перехватывание вызовов любых объектов
Model — интерфейс, ModelMap его реализация..
ModelAndView является контейнером для пары, как ModelMap и View.
Обычно я люблю использовать ModelAndView. Однако есть так же способ когда мы задаем необходимые атрибуты в ModelMap, и возвращаем название View обычной строкой из метода контроллера.
Метод addAttribute отделяет нас от работы с базовой структурой hashmap. По сути addAttribute это обертка над put, где делается дополнительная проверка на null. Метод addAttribute в отличии от put возвращает modelmap.
model.addAttribute(“attribute1”,”value1”).addAttribute(“attribute2”,”value2”);
Нам это может понадобиться, если мы, например, захотим взять некоторое значение с HTML страницы и сохранить его в БД. Для этого нам надо это значение переместить в контроллер Спринга.
Если мы будем использовать Spring MVC form tags, Spring автоматически свяжет переменные на HTML странице с Бином Спринга.
Если мне придется с этим работать, я обязательно буду смотреть официальную документацию Spring MVC Form Tags.
Hibernate Validator никак не связан с БД. Это просто библиотека для валидации.
Hibernate Validator версии 5.x является эталонной реализацией Bean Validation 1.1
Так же если взглянуть по адресу http://beanvalidation.org/2.0, то Hibernate Validator является единственным, который сертифицирован.
Расположение статических ресурсов можно настроить. В документации Spring Boot рекомендуется использовать /static, или /public, или /resources, или /META-INF/resources
В случае GET запроса передаваемые параметры являются частью url, и все маршрутизаторы, через которые пройдет наш GET запрос, смогут их прочитать.
В случае POST запроса передаваемые параметры являются частью тела запроса. При использовании HTTPs, тело запроса шифруется. Следовательно, использование POST запросов является более безопасным
Пример:
http://localhost:8080/login?name=Ranga&name=Ravi&name=Sathish
Да, можно принять все значения, используя массив в методе контроллера
Хочу поблагодарить пользователя хабра jd2050, за помощь с переводом.
Введение в Spring, или что делать, если по всему проекту @Autowired и @Component, а вы не понимаете, что это
Приветствую тебя, Хабр!
Эта статья будет полезна тем, кто уже начал изучать Java и даже успел добиться некоторых успехов в понимании Java Core, и вот услышал слово Spring. И, возможно, даже не один раз: знание Spring Framework, как минимум, фигурирует в описаниях множества вакансий для джавистов. Эта статья поможет вам взобраться на самую первую ступеньку: понять общую идею столь популярного фреймворка.
Начнем издалека. Существует такое понятие как Inversion of Control, по-русски – Инверсия управления, сокращенно – IoC. IoC — один из принципов, приближающий наш код к слабосвязанности. IoC — это делегирование части наших обязанностей внешнему компоненту.
Существуют разные реализации IoC подхода, нас интересует одна из них — Dependency Injection, внедрение зависимостей. Что это такое, название говорит само за себя, так что раскрыть ее я постараюсь на примере. Мы пишем приложение, автоматизирующее работу сети магазинов. Есть классы Shop (магазин) и Seller (продавец). У класса Seller имеется поле типа Shop — магазин, в котором работает продавец. Вот мы и столкнулись с зависимостью: Seller зависит от Shop. Теперь задумаемся, как в объект Seller попадет объект Shop? Есть варианты:
Перечисленные два способа — это реализация Dependency Injection (но пока еще это не IoC). И, наконец, мы подобрались к спрингу: он предоставляет еще один способ внедрять зависимости (а тут уже IoC).
Вообще говоря, Spring — это очень широкий набор библиотек на многие случаи жизни. Существует и Spring MVC для быстрого создания веб-приложений, и Spring Security для реализации авторизации в приложении, и Spring Data для работы с базами данных и еще куча всего. Но отдельно стоит Spring IoC — это базовый вид спринга, который реализует изучаемую нами тему — внедрение зависимостей. Spring IoC заслуживает внимания в самом начале изучения библиотек спринга по еще одной причине. Как вы увидите в процессе практической работы с другими видами спринга, для всех остальных спрингов Spring IoC используется как каркас.
Знакомство со Spring IoC начнем с главного термина: бин (англ. — bean). Самыми простыми словами,
Бин — создаваемый Spring-ом объект класса, который можно внедрить в качестве значения поля в другой объект.
Бин — объект класса, представляющий собой завершенный программный элемент с определенной бизнес-функцией либо внутренней функцией Spring’а, жизненным циклом которого управляет контейнер бинов.
Как вы уже поняли, для того, чтобы в Seller можно было внедрить Shop, Shop должен стать бином. Существует несколько способов рассказать приложению, какие объекты имеют гордое право называться бинами, все они приводят нас к понятию ApplicationContext. ApplicationContext — это сердце спринга. Как правило, он создается в самом начале работы приложения («поднимается») и управляет жизненным циклом бинов. Поэтому его еще называют контейнером бинов.
Подбираемся к главному. Каким образом нам необходимо переписать наши классы, чтобы Spring IoC и его слуга ApplicationContext подставили значение поля Shop объекту Seller? Вот таким:
Просто? Куда уж проще! Элегантно? Вполне. Здесь произошло следующее: аннотация Component сказала спрингу, что класс, который ей аннотируем, это бин. Аннотация Autowired попросила Spring в поле, которое она аннотирует, подставить значение. Эта операция называется «инжектнуть» (inject). Какое именно значение будет подставлено? Об этом чуть позже, сначала разберемся, как вообще классы становятся бинами.
Мы уже знаем, что в начале работы приложения должен подняться хранитель всех бинов ApplicationContext. Он-то и создает сразу все бины. Почти все. Дело в том, что по умолчанию любой бин имеет внутриспринговое свойство scope в значении singleton. Внутриспринговое, так как синглтоном в прямом смысле слова он не является. Он является синглтоном для спринга: при поднятии контекста Spring создаст ровно один объект-бин из указанного класса. Если вы хотите изменить такое поведение — пожалуйста, Spring разрешает управлять временем создания бина и их количеством для одного класса, но сейчас не об этом.
Итак, при поднятии ApplicationContext создаются все бины. Давайте выясним, а собственно где живет контекст и самое главное: как он определяет, из каких классов необходимо создавать бины. Вариантов несколько, для простоты изложения мы поговорим про один из них: конфигурирование с помощью файла xml. Вот его пример:
В этом файле продемонстрирован запуск создания бинов двумя путями. Первый, скажем так, ручной. Видите, здесь есть тег bean с указанием класса. Это и есть бин. Из всего, что прописано в этом файле с тегом bean, будут созданы бины.
Второй путь менее многословен. Помните, над классами мы поставили аннотацию Component. Из всех классов, аннотированных этой аннотацией, будут созданы бины. Благодаря этой строке из xml-файла:
Она говорит спрингу: просканируй весь пакет main и из всего, над чем будет стоять аннотация Component (или другие аннотации, являющиеся наследниками Component), создай бины. Компактно, не правда ли? Просто говорим, в каких пакетах содержатся классы, из которых нужно создавать бины, и аннотируем эти классы.
Поднять контекст с использованием xml-файла можно следующей строчкой кода:
где beans.xml — путь к xml-нику, о котором шла речь выше.
С созданием бинов разобрались. Каким же образом Spring заполнит поле Shop при создании Seller’а? При поднятии контекста создается бин-объект класса Shop. Также создается бин-объект класса Seller, он же тоже аннотирован Component. У него есть поле типа Shop, аннотированное Autowired. Аннотация Autowired говорит спрингу: в это поле нужно инжектнуть бин. В нашем случае у нас есть всего один бин, подходящий на эту роль, то есть тип которого совпадает с типом поля: это бин — экземпляр класса Shop. Он и будет проинжектен в объект Seller, что и требовалось. Я понимаю, сейчас вопросики полезли как червячки: а что будет, если Spring не найдет нужный бин, или найдет несколько подходящих (особенно учитывая, что инжектить можно также по интерфейсу, а не по классу). Spring умен, но требует того же и от нас. Нам нужно либо иметь в системе ровно один бин, подходящий под каждый Autowired, либо обучать Spring действиям при таких конфликтах (об этом мы сейчас не будем, вы и так устали, крепитесь, статья подходит к концу).
Заметьте, что Seller – это тоже бин. Если бы он был не бином, а создавался через new, то автоматически бы ничего в него не проинжектнулось.
Возможно вы сейчас думаете, зачем все эти сложности. Но представьте, что у нас приложение не из 2 классов, а на несколько порядков больше и управление зависимостями уже становится не самой тривиальной задачей.
Возможно вы сейчас думаете, как красиво, просто и лаконично Spring позволяет внедрять зависимости. Но представьте, что что-то пошло не так и вам необходимо дебажить приложение. И все становится уже не так просто…
Парочка хинтов напоследок:
Это легальный способ получить бин, хотя в современных реалиях так обычно не делают. Но для учебного примера можно.
UPD (20.04.2021). Dependency Injection это не всегда IoC! В самом начале я как раз привожу примеры Dependency Injection, не являющиеся IoC.
Spring. Для чего нужен cервис-слой?
Во всех гайдах дают такую структуру проекта:
В тех же гайдах глядя в код видно только то, что сервис-слой полностью дублирует DAO. Для чего всё таки нужен этот слой? Как его правильно использовать?
Это общие слова и терминология человека, понимающего досконально или почти досконально структуру и принципы взаимодействия внутри контейнера Спринг. Да и логика очень часто несложная в сервисах — получить данные и иногда трансформировать их для отдачи контроллем. Понятно, встречаются и сложные сервисы, но в подавляющем большинстве это просто получение данных из базы по критериям.
Пользуясь не один год этим фреймворком, тоже часто грешил тем, что выкидывал сервис-слой, делегируя его функционал слою DAO (только как правильно заметил один гуру с одного ресурса, в терминологии Спринга называть этот слой правильно не DAO, а репозиторий — Repository). Было просто и удобно, тем более, что при небольших проектах фактически код в дао и сервисе повторяются. А различия заключаются в том, что @ Repository — наш DAO — это бин-синглтон, и при доступе к нему несколькими потоками, что для MVC — нормальная вещь, может произойти доступ к одним данным из разных потоков. Видимость же @ Service определена видимостью вызывающего @ Controller. Возможно, с определением и терминологией наблюдаются у меня некоторые напряги, да и тонкую настройку компонентов наверняка можно сделать, но общий принцип и назначение переданы.
Где Должна Храниться аннотация Spring @Service?
1. введение
Как разработчики программного обеспечения, мы всегда ищем лучшие практики использования данной технологии или библиотеки. Естественно, иногда возникают споры.
В этом уроке мы рассмотрим аннотацию @Service и рассмотрим, лучше ли ее размещать на интерфейсах, абстрактных классах или конкретных классах .
2. @Service на интерфейсах
Некоторые разработчики могут решить поставить @Service на интерфейсы, потому что они хотят:
Давайте посмотрим, как это выглядит, если мы аннотируем интерфейс:
Как мы заметили, Служба аутентификации теперь становится более самоописательной. Знак @Service советует разработчикам использовать его только для служб бизнес-уровня, а не для уровня доступа к данным или любых других уровней.
Обычно это нормально, но есть один недостаток. Помещая @Service Spring в интерфейсы, мы создаем дополнительную зависимость и соединяем наши интерфейсы с внешней библиотекой.
Затем, чтобы проверить автоматическое обнаружение наших новых компонентов службы, давайте создадим реализацию нашей службы Аутентификации :
Итак, давайте запустим наш контекст Spring с помощью базовой настройки загрузки Spring:
Когда мы запускаем наше приложение, мы получаем печально известное NoSuchBeanDefinitionException, и контекст Spring не запускается:
3. @Сервис по абстрактным классам
Использование аннотации @Service для абстрактных классов не является обычным явлением.
Давайте проверим его, чтобы увидеть, достигает ли он нашей цели-заставить Spring автоматически определять наши классы реализации.
Мы начнем с определения абстрактного класса с нуля и размещения на нем аннотации @Service :
Далее мы расширяем Абстрактную службу аутентификации до создания конкретной реализации без ее аннотирования :
Итак, мы снова запускаем наше приложение Auth :
Как мы видим, весенний контекст не начинается. Это заканчивается тем же NoSuchBeanDefinitionException исключением.
4. @Сервис по конкретным классам
Вопреки тому, что мы видели выше, довольно распространенной практикой является аннотирование классов реализации вместо абстрактных классов или интерфейсов.
Таким образом, Spring автоматически определит эти классы из пути к классам и автоматически определит их как управляемые компоненты.
Итак, давайте на этот раз поставим @Service на наши конкретные классы обслуживания. У нас будет один класс, реализующий наш интерфейс, и второй, расширяющий абстрактный класс, который мы определили ранее:
Здесь мы должны обратить внимание на то, что наша Абстрактная служба аутентификации не реализует Службу аутентификации здесь. Следовательно, мы можем проверить их независимо.
Наконец, мы добавляем оба наших класса обслуживания в приложение Auth и даем ему попробовать:
5. Результат
В конце концов, мы увидели, что единственный рабочий способ-это поместить @Service в наши классы реализации, чтобы сделать их автоматически обнаруживаемыми. Сканирование компонентов Spring не собирает классы, если они не аннотированы отдельно, даже если они получены из другого @Service аннотированного интерфейса или абстрактного класса.
Кроме того, в документации Spring также говорится, что использование @Service в классах реализации позволяет автоматически обнаруживать их при сканировании компонентов.
6. Заключение
В этой статье мы рассмотрели различные места использования аннотации Spring @Service и узнали, где хранить @Service для определения компонентов Spring уровня обслуживания, чтобы они были автоматически обнаружены во время сканирования компонентов.