Паттерны проектирования, используемые в Spring Framework

Автор оригинала: Ramesh Fadatare
  • Перевод

Привет, хабровчане! Длинные выходные завершились, а это значит, что пришло время поделиться новым полезным переводом. Сегодня поговорим о паттернах проектирования, используемых в Spring Framework. Как вы догадались, данный материал приурочен к старту набора новой группы по курсу "Разработчик на Spring Framework", который стартует 28 мая. Начнем.



В этой статье сделаем обзор нескольких паттернов проектирования, которые широко используются в Spring Framework. Паттерны проектирования описывают приёмы программирования в объектно-ориентированной разработке программного обеспечения.


Вот некоторые известные паттерны, используемые в Spring Framework:


  • Proxy (Заместитель)
  • Singleton (Одиночка)
  • Factory (Фабрика)
  • Template (Шаблон)
  • Model View Controller (Модель-Представление-Контроллер)
  • Front Controller (Контроллер запросов)
  • View Helper (Вспомогательный компонент представления)
  • Dependency injection и Inversion of control (IoC) (Внедрение зависимостей и инверсия управления)
  • Service Locator (Локатор служб)
  • Observer-Observable (Наблюдатель)
  • Context Object (Контекстный объект)

Proxy (Заместитель)


Паттерн Proxy широко используется в AOP и remoting.


Хороший пример использования Proxy — это org.springframework.aop.framework.ProxyFactoryBean.


Эта фабрика создаёт AOP-прокси на основе Spring-бина.


Прокси предоставляет заместителя для другого объекта, чтобы контролировать доступ к нему.


Прочитать больше про Proxy вы можете здесь.


Singleton (Одиночка)


Паттерн Singleton гарантирует, что в памяти будет существовать только один экземпляр объекта, который будет предоставлять сервисы.


В Spring область видимости бина (scope) по умолчанию равна singleton и IoC-контейнер создаёт ровно один экземпляр объекта на Spring IoC-контейнер.


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


Рекомендуется использовать область видимости singleton для бинов без состояния.


Область видимости бина можно определить как singleton или как prototype (создаётся новый экземпляр при каждом запросе бина).


Пример конфигурации в xml-файле:


<!-- Определение бина с областью видимости singleton -->
<bean id = "..." class = "..." scope = "singleton/prototype">
   <!-- здесь конфигурация бина -->
</bean>

Почитать больше про Singleton вы можете здесь.


Factory (Фабрика)


Этот паттерн позволяет инициализировать объект через публичный статический метод, называемый фабричным методом.


Spring использует паттерн Factory для создания объекта бина с использованием следующих двух подходов.


  • BeanFactory


    Простой контейнер, который обеспечивает базовую поддержку DI (Dependency Injection, инъекция зависимостей). Для работы с этим контейнером используется интерфейс org.springframework.beans.factory.BeanFactory.


  • ApplicationContext



Другой контейнер, присутствующий в Spring, который добавляет специфичные enterprise-функции. Эти функции включают в себя возможность чтения параметров из property-файлов и публикацию событий приложения для слушателей событий.


Для работы с этим контейнером используется интерфейс org.springframework.context.ApplicationContext.


Ниже приведены наиболее часто используемые реализации ApplicationContext.


  • FileSystemXmlApplicationContext — в конструкторе необходимо указать полный путь к XML-файлу с конфигурацией бинов.


  • ClassPathXmlApplicationContext — необходимо поместить XML-файл с конфигурацией бинов в CLASSPATH.


  • XmlWebApplicationContext — загружает XML-файл с метаданными бинов в веб-приложении.



Примеры:


package com.eduonix.springframework.applicationcontext;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class App {
  public static void main(String[] args) {
    ApplicationContext context = new FileSystemXmlApplicationContext(
       "C:/work/IOC Containers/springframework.applicationcontext/src/main/resources/bean-factory-config.xml");

    HelloApplicationContext obj = (HelloApplicationContext) context.getBean("helloApplicationContext");
    obj.getMsg();
  }
}

Чтобы лучше понять это, давайте рассмотрим реальный пример. Сначала конфигурацию:


<bean id="welcomerBean" class="com.mysite.Welcomer" factory-method="createWelcomer">
  <constructor-arg ref="messagesLocator"></constructor-arg>
</bean>

<bean id="messagesLocator" class="com.mysite.MessageLocator">
  <property name="messages" value="messages_file.properties"></property>
</bean>

А теперь бин:


public class Welcomer {
  private String message;

  public Welcomer(String message) {
    this.message = message;
  }

  public static Welcomer createWelcomer(MessageLocator messagesLocator) {
    Calendar cal = Calendar.getInstance();
    String msgKey = "welcome.pm";
    if (cal.get(Calendar.AM_PM) == Calendar.AM) {
      msgKey = "welcome.am";
    }
    return new Welcomer(messagesLocator.getMessageByKey(msgKey));
  }
}

Почитать больше про Factory вы можете здесь.


Template (Шаблон)


Этот паттерн широко используется для работы с повторяющимся бойлерплейт кодом (таким как, закрытие соединений и т. п.).
Например, JdbcTemplate, JmsTemplate, JpaTemplate (Примечание переводчика: JpaTemplate объявлен устаревшим с Spring 3.1).


Почитать больше про Template вы можете здесь.


Model View Controller (Модель-Представление-Контроллер)


Преимущество Spring MVC в том, что ваши контроллеры являются POJO, а не сервлетами. Это облегчает тестирование контроллеров. Стоит отметить, что от контроллеров требуется только вернуть логическое имя представления, а выбор представления остаётся за ViewResolver. Это облегчает повторное использование контроллеров при различных вариантах представления.


Почитать больше про Model View Controller вы можете здесь.


Front Controller (Контроллер запросов)


Spring предоставляет DispatcherServlet, чтобы гарантировать, что входящий запрос будет отправлен вашим контроллерам.


Паттерн Front Controller используется для обеспечения централизованного механизма обработки запросов, так что все запросы обрабатываются одним обработчиком. Этот обработчик может выполнить аутентификацию, авторизацию, регистрацию или отслеживание запроса, а затем передать запрос соответствующему контроллеру.


Почитать больше про Front Controller вы можете здесь.


View Helper (Вспомогательный компонент представления)


В Spring есть несколько пользовательских JSP-тегов и макросов Velocity, помогающие отделить код от представления.


View Helper отделяет статическое содержимое в представлении, такое как JSP, от обработки бизнес-логики.


Фреймворки, такие как Spring и Struts, предоставляют собственные библиотеки тегов для инкапсуляции логики обработки в хелперах вместо размещения логики в представлении, таком как JSP-файлы.


Почитать больше про View Helper вы можете здесь.


Dependency injection и inversion of control (IOC) (Внедрение зависимостей и инверсия управления)


IoC-контейнер в Spring, отвечает за создание объекта, связывание объектов вместе, конфигурирование объектов и обработку всего их жизненного цикла от создания до полного уничтожения.


В контейнере Spring используется инъекция зависимостей (Dependency Injection, DI) для управления компонентами приложения. Эти компоненты называются "Spring-бины" (Spring Beans).


Почитать больше про Dependency Injection вы можете здесь.


Service Locator (Локатор служб)


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


Паттерн Service Locator используется, когда мы хотим найти различные сервисы, используя JNDI. Учитывая высокую стоимость поиска сервисов в JNDI, Service Locator использует кеширование. При запросе сервиса первый раз Service Locator ищет его в JNDI и кэширует объект. Дальнейший поиск этого же сервиса через Service Locator выполняется в кэше, что значительно улучшает производительность приложения.


Почитать больше про Service Locator вы можете здесь.


Observer-Observable (Наблюдатель)


Используется в механизме событий ApplicationContext.
Определяет зависимость "один-ко-многим" между объектами, чтобы при изменении состояния одного объекта все его подписчики уведомлялись и обновлялись автоматически.


Почитать больше про Observer вы можете здесь.


Context Object (Контекстный объект)


Паттерн Context Object, инкапсулирует системные данные в объекте-контексте для совместного использования другими частями приложения без привязки приложения к конкретному протоколу.


ApplicationContext является центральным интерфейсом в приложении Spring для предоставления информации о конфигурации приложения.


Почитать больше про Context Object вы можете здесь.


Ссылки


https://stackoverflow.com/questions/755563/what-design-patterns-are-used-in-spring-framework


Вот такой вышел материал. Ждем ваши комментарии и приглашаем на бесплатный вебинар, в рамках которого разработаем полноценное классическое Web-приложение с UI, аутентификацией и авторизацией. Также изучим особенности Web-приложений и попробуем решить некоторые задачи Enterprise который. Вебинар пройдет уже сегодня.

OTUS. Онлайн-образование
Цифровые навыки от ведущих экспертов

Похожие публикации

Комментарии 6

    +1
    Статья из серии назад в будущее? :)
      +1
      Просто интересно — кто дает вам статьи на публикацию?
      И будут ли обучать писать так код на ваших курсах?
      Информация из статьи устарела на несколько лет — так сейчас не пишут — только сопровождают легаси код.
        +1
        Представьте. Если Вы не знакомы с Spring Framework и услышали про него в первый раз то Spring Boot для вас будет «чёрной чёрной коробкой в чёрном чёрном доме на чёрной чёрной улице». Чтобы такого не было — Вас ждёт увлекательный и нудный путь от ручного программирования с Service Locator к использованию DI, от ручной настройки через файлы к аннотациям, от ручного деплоя ваших war в /webapp до использования встроенных встроенных сервлет контейнеров, от явного прописования

        А как вы хотели, чтобы всё было: «Фигак, фигак и в продакшн»?
          0

          А я даже не про бут. Просто хотя бы AnnotationContext и погнали. XML за рамками добра и зла.

            0
            «так сейчас не пишут» воспринял именно как намёк на Spring Boot. И web/консольные проекты действительно стали писать преимущественно с ним.
              0

              Для продакшена Boot действительно отличный выбор. Но он не даёт понимания того как работает спринг как di Фреймворк.
              А после понимания этого можно спокойно перелазить на бут и не морочить голову с деплоем — это очень рутинная операция

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое