В основном весна является основой для внедрение зависимости это образец, который позволяет строить очень несвязанные системы.
Проблема
Например, предположим, что вам нужно перечислить пользователей системы и, таким образом, объявить интерфейс с именем UserLister:
public interface UserLister {
List<User> getUsers();
}
И, возможно, реализация доступа к базе данных, чтобы получить всех пользователей:
public class UserListerDB implements UserLister {
public List<User> getUsers() {
// DB access code here
}
}
По вашему мнению, вам нужно получить доступ к экземпляру (просто пример, помните):
public class SomeView {
private UserLister userLister;
public void render() {
List<User> users = userLister.getUsers();
view.render(users);
}
}
Обратите внимание, что приведенный выше код не инициализировал переменную userLister . Что нам делать? Если я явно создаю экземпляр объекта следующим образом:
UserLister userLister = new UserListerDB();
... Я бы связал представление с моей реализацией класса, который обращается к БД. Что если я захочу перейти от реализации БД к другой, которая получает список пользователей из файла, разделенного запятыми (помните, это пример)? В этом случае я бы снова пошел к своему коду и изменил строку выше:
UserLister userLister = new UserListerCommaSeparatedFile();
Это не проблема для такой маленькой программы, как эта, но ... Что происходит в программе, которая имеет сотни представлений и такое же количество бизнес-классов? Техническое обслуживание становится кошмаром!
Подход Spring (Dependency Injection)
Что делает Spring, так это связывает классы с помощью XML-файла или аннотаций, таким образом все объекты создаются и инициализируются Spring и внедряются в нужных местах (сервлеты, веб-фреймворки, бизнес-классы, DAO и т. Д. И т. Д. И т. Д. И т. Д. И т. Д., И т. Д.) ...).
Возвращаясь к примеру в Spring, нам просто нужно иметь установщик для userListerполя и иметь XML-файл, подобный этому:
<bean id="userLister" class="UserListerDB" />
<bean class="SomeView">
<property name="userLister" ref="userLister" />
</bean>
или, более просто, аннотируйте поле в нашем классе представления с помощью @Inject:
@Inject
private UserLister userLister;
Таким образом, когда представление будет создано, оно волшебным образом будет UserListerготово к работе.
List<User> users = userLister.getUsers(); // This will actually work
// without adding any line of code
Это просто супер! Не так ли?
- Что если вы хотите использовать другую реализацию вашего
UserListerинтерфейса? Просто измените XML.
- Что, если у вас нет
UserListerготовой реализации? Запрограммируйте временную реализацию UserListerи упростите разработку представления.
- Что если я больше не хочу использовать Spring? Только не используйте это! Ваше приложение не связано с ним. Инверсия управления гласит: «Приложение контролирует структуру, а не среда контролирует приложение».
Есть несколько других вариантов внедрения зависимостей, что, на мой взгляд, сделало Spring настолько известным, кроме своей простоты, элегантности и стабильности, что ребята из SpringSource запрограммировали множество POJO, которые помогают интегрировать Spring со многими другими общими фреймворками без навязчиво в вашем приложении. Кроме того, у Spring есть несколько хороших подпроектов, таких как Spring MVC, Spring WebFlow, Spring Security и, опять же, огромный список и так далее.
Надеюсь это поможет. В любом случае, я призываю вас прочитать статью Мартина Фаулера о внедрении зависимости и инверсии контроля, потому что он делает это лучше меня. После понимания основы взглянуть на Спринг документации , на мой взгляд, это будет использоваться , чтобы быть лучшей книгой Spring когда - либо.
