Какие шаблоны проектирования используются в среде Spring?
Какие шаблоны проектирования используются в среде Spring?
Ответы (9)
Существует множество различных шаблонов проектирования, но есть несколько очевидных:
Прокси — активно используется в AOP и удаленное взаимодействие.
Singleton — bean-компоненты, определенные в конфигурационных файлах spring, по умолчанию являются синглтонами.
Шаблонный метод - широко используется для работы с шаблонным повторяющимся кодом (например, чистое закрытие соединений и т. Д.). Например, JdbcTemplate, JmsTemplate, JpaTemplate.
Обновите следующие комментарии: для MVC вы можете прочитать справочник по MVC.
Некоторые очевидные шаблоны, используемые в MVC:
Контроллер представления модели :-) . Преимущество Spring MVC заключается в том, что ваши контроллеры являются POJO, а не сервлетами. Это упрощает тестирование контроллеров. Следует отметить, что от контроллера требуется только возврат имени логического представления, а выбор представления оставлен для отдельного ViewResolver. Это упрощает повторное использование контроллеров для различных технологий просмотра.
Фронт-контроллер. Spring предоставляет DispatcherServlet чтобы убедиться, что входящий запрос отправляется на ваши контроллеры.
Помощник по представлениям — Spring имеет ряд пользовательских тегов JSP и макросы скорости. , чтобы помочь отделить код от представления в представлениях.
Foo
, и вы получаете экземпляр Foo
для каждого контекста, вы получите две разные ссылки на объекты. Вместо этого здесь применен шаблон проектирования облегченный.
- person Luiggi Mendoza; 05.05.2014
JdbcTemplate
и его друзей в качестве примера шаблонного метода очень распространено, но я думаю, что они имеют мало общего с этим шаблоном (кроме названия). Или же мы можем назвать почти все случаи, когда вы расширяете класс, чтобы переопределить некоторые защищенные методы, примером шаблона метода шаблона.
- person ddekany; 26.11.2017
И, конечно же, внедрение зависимостей или IoC (инверсия управления), которое является центральным элементом всего BeanFactory/ApplicationContext.
DI на самом деле является своего рода стратегией. Всякий раз, когда вы хотите, чтобы какая-то логика/реализация заменялись, вы обычно находите интерфейс и соответствующий метод установки в классе хоста для подключения вашей пользовательской реализации этого интерфейса.
Spring — это коллекция шаблонов API с передовой практикой, вы можете составить их список покупок, сколько угодно. То, как спроектирован API, побуждает вас (но не принуждает) следовать этим шаблонам, и в половине случаев вы следуете им, не подозревая об этом.
Шаблон локатора службы — ServiceLocatorFactoryBean хранит информацию обо всех bean-компонентах в контексте. Когда клиентский код запрашивает службу (компонент), используя имя, он просто находит этот компонент в контексте и возвращает его. Клиентскому коду не нужно писать код, связанный с Spring, чтобы найти bean-компонент.
Observer-Observable: используется в механизме событий ApplicationContext.
Шаблон Factory также используется для загрузки bean-компонентов через контекст BeanFactory и Application.
Шаблон метода Factory: BeanFactory для создания экземпляра объекта Singleton: тип экземпляра может быть singleton для контекста Prototype: тип экземпляра может быть прототипом. Шаблон Builder: вы также можете определить метод в классе, который будет отвечать за создание сложного экземпляра.
Контейнер Spring генерирует объекты bean-компонентов в зависимости от области bean-компонента (синглтон, прототип и т. д.). Итак, это похоже на реализацию шаблона Abstract Factory. Я уверен, что во внутренней реализации Spring каждая область должна быть привязана к определенному классу фабрики.