думать
Spring занимает половину нашей среды разработки Java, и мы используем Spring с самого начала нашей работы. Но зачем использовать Spring, может многие не задумывались над этой проблемой? Многие также могут быть слишком перегружены спросом, чтобы думать о такой, казалось бы, естественной проблеме. Итак, сегодня давайте обсудим, почему мы должны использовать Spring IOC?
Обратное мышление
Предположим, что когда вначале не было фреймворка Spring IOC, мы использовали традиционный метод MVC для разработки общей пользовательской логики.
ДАО пользователя
public class UserDAO {
private String database;
public UserDAO(String dataBase) {
this.database = dataBase;
}
public void doSomething() {
System.out.println("保存用户！");
}
}
Служба пользователя
public class UserService {
private UserDAO dao;
public UserService(UserDAO dao) {
this.dao = dao;
}
public void doSomething() {
dao.doSomething();
}
}
Пользовательский контроллер
public class Controller {
public UserService service;
public Controller(UserService userService) {
this.service = userService;
}
public void doSomething() {
service.doSomething();
}
}
Далее мы должны вручную создавать объекты один за другим, и собрать DAO, Service и Controller, перед вызовом.
public static void main(String[] args) {
UserDAO dao = new UserDAO("mysql");
UserService service = new UserService(dao);
Controller controller = new Controller(service);
controller.doSomething();
}
Каковы недостатки этого подхода?
- В месте, где генерируется контроллер, мы должны сначала создать дао, затем создать сервис и, наконец, создать контроллер, такой громоздкий процесс создания.
- В трехслойной структуре верхний слой должен знать, как создается нижний слой, а верхний слой должен сам создавать нижний слой, таким образом образуя тесную связь. Почему бизнес-программисты должны знать пароль базы данных и создавать дао самостоятельно при написании бизнеса? Мало того, когда пароль базы данных dao изменяется, его необходимо изменить в каждом месте, где генерируется контроллер.
- Конкретный объект генерируется через ключевое слово new, что жестко закодировано и нарушает принципы интерфейсно-ориентированного программирования. Когда однажды мы перешли с Hibernate на Mybatis, нам нужно было заменить каждый новый DAO.
- Мы часто создаем объекты, тратя ресурсы впустую.
На этот раз давайте посмотрим на ситуацию с Springioc, код только что превратился в следующее.
public static void main(String[] args) {
ApplicationContext context = new ClassPathXmlApplicationContext("classpath:application.xml");
Controller controller = (Controller) context.getBean("controller");
controller.doSomething();
}
Очевидно, что после использования IOC мы просто запрашиваем у контейнера требуемые бины. IOC решает следующие проблемы:
- Развязка между бинами, что выражается в том, что мы не прописываем жестко зависимости между бинами в коде. (Вместо того, чтобы создавать объекты по очереди с помощью новой операции, springIOC помогает нам реализовать внедрение зависимостей внутри). С одной стороны, контейнер IOC изменит способ установки зависимостей через новые объекты на динамическую установку зависимостей во время выполнения.
- Контейнер IOC естественным образом дает нам синглтоны.
- Когда нам нужно заменить dao, нам нужно всего лишь заменить класс реализации dao в файле конфигурации, что совершенно не разрушит предыдущий код.
- Верхнему слою теперь не нужно знать, как был создан нижний слой.
На этом примере читатель может немного задуматься, поэтому давайте посмотрим, что такое определение IOC.
определение
Инверсия управления (сокращенно IoC) — это принцип проектирования в объектно-ориентированном программировании, который можно использовать для уменьшения связи между компьютерными кодами. Наиболее распространенный способ называется внедрение зависимостей (DI), и есть еще один способ, называемый «поиск зависимостей». При инверсии управления объектам передаются ссылки на объекты, от которых они зависят, когда они создаются внешним объектом, который управляет всеми объектами в системе. Можно также сказать, что зависимости внедряются в объекты.
интерпретировать
Инверсия управления, где проявляется управление? Управление отражено в нашем первом примере, верхний слой должен управлять новым объектом нижнего слоя. И что значит инверсия? Инверсия означает, что мы передаем управление созданием объекта кому? Передайте его IOC-контейнеру, а IOC-контейнер отвечает за создание конкретных объектов и заполнение мест, где требуются конкретные объекты для каждого объявления. Студенты могут запутаться в IOC и DI. Фактически, IOC эквивалентен интерфейсу. Он определяет, чего достичь? А Dependency Injection (DI) — это конкретная реализация, которая достигает желаемого эффекта от IOC. Идея IOC воплощает один из принципов объектно-ориентированного проектирования — голливудский закон: «не найдите нас, мы найдем вас»; то есть IoC-контейнер помогает объекту найти соответствующий зависимый объект и внедрить его , а не объект, активно находящий его.
Как уменьшить сцепление? Например, когда мы добавляем плагин в среду разработки IDEA, нам нужно знать, какие зависимости нужны плагину.Как мы можем успешно открыть плагин? Это довольно недружественно для пользователей? Поскольку мы собираемся использовать плагины, это означает, что мы связаны с плагинами, и этого нельзя избежать. Но если нам также нужно знать зависимости, требуемые подключаемым модулем, и шаги для открытия подключаемого модуля, это означает, что связь между нами и подключаемым модулем сильнее. Таким образом, определение SpringIOC читается как «уменьшение связи», а не «устранение связи», но до тех пор, пока степень связи уменьшается, это способствует поддержанию и расширению кода. подумать ненадолго? Это похоже на механизм Maven? Если вы объявляете зависимость в Maven, Maven автоматически ищет другие зависимости, требуемые этой зависимостью, рекурсивно. Вы можете представить себя дизайнером объекта: вы проектируете чертеж внутренней структуры объекта и отдаете его в SpringIOC, который автоматически сгенерирует объект на основе чертежа.
Контейнер IOC реализует компонентизацию детализации объектов при разработке и помещает каждый объект в контейнер как компонент. И каждый компонент подключаемый, что является лучшим способом разделения объектов. С одной стороны, перенося связь между объектами с момента компиляции на время выполнения. Как только объект необходим, его можно использовать напрямую, и клиентскому программисту вообще не нужно знать все тонкости этого объекта. А унифицированное управление бинами IOC-контейнером делает реализацию АОП более удобной. Таким образом, наши клиентские программисты могут больше сосредоточиться на написании бизнес-кода.