О чем Внедрение зависимости и Платформа Spring? [дубликат]
10 ответов
Для реализации свободной муфты мы используем Dependency Injection (DI). Выбор любого конкретного контейнера DI не так важен.
Каждый раз, когда вы создаете экземпляр класса, используя ключевое слово new, вы плотно связываете свой код с этим классом, и вы не сможете заменить эту конкретную реализацию на другую (по крайней мере, без перекомпиляции кода).
Это выглядело бы примерно так на C# (но было бы эквивалентно на Java):
public class MyClass
{
public string GetMessage(int key)
{
return new MessageService().GetMessage(key)
}
}
Это означает, что если вы позже захотите использовать другой MessageService, то вы не сможете. С другой стороны, если вы введете интерфейс в класс и будете придерживаться принципа оценки Лискова Liskov Substition Principle, вы сможете самостоятельно менять потребителя и услугу.
public class MyClass
{
private readonly IMessageService messageService;
public MyClass(IMessageService messageService)
{
if(messageService == null)
{
throw new ArgumentNullException("messageService");
}
this.messageService = messageService;
}
public string GetMessage(int key)
{
return this.messageService.GetMessage(key)
}
}
Хотя это выглядит сложнее, теперь нам удалось следовать принципу Single Responsibility Principle , гарантируя, что каждый сотрудник делает только одно, и что мы можем варьировать и то, и другое независимо друг от друга.
Более того, теперь мы можем изменить поведение MyClass, не изменяя сам класс, таким образом, придерживаясь принципа Open/Closed Principle .
.Может быть, не стоит пытаться провести "Java enterprise development", не имея представления об основных архитектурных и дизайнерских заботах? Я предлагаю Вам либо найти опытного сотрудника, который готов Вам помочь, либо вложить больше усилий в чтение этих книг, либо пройти курс обучения.
В любом случае, на Ваш вопрос нет "простого ответа"
.Реконфигурация переоценена. Самое главное, что вы получаете от использования DI - это -тестируемость. Так как ваши классы зависят не от реализаций, а от абстракций, вы можете заменить их в юнит-тестах имитациями/корешками.
Пример
Без DI:
class SaleAction{
private BillingService billingService;
public SaleAction(){
billingService = new CreditCardService(); //dependency is hardcoded
}
public void pay(long amount){
//pre payment logic
billingService.pay(amount);
//post payment logic
}
}
В этом примере предположим, что вы хотите юнит-тестировать логику предоплаты и постоплаты в SaleAction. ... вы не можете, потому что SaleAction связан с CreditCardService и, вероятно, запуск ваших тестов сгенерирует фальшивые платежи.
Теперь тот же пример с DI:
class SaleAction{
private BillingService billingService;
public SaleAction(BillingService service){
billingService = service; //DI
}
public void pay(long amount){
//pre payment logic
billingService.pay(amount);
//post payment logic
}
}
Теперь SaleAction отделен от любой реализации, что означает, что в вашем тесте вы можете сделать SaleAction action = new SaleAction(new DummyBillingService());.
Надеюсь, это поможет, есть также статья Мартина Фаулера о DI, написанная им, которую вы можете найти здесь
Весна превратилась в огромный каркас, что может сбить вас с толку, если вы только пытаетесь обернуть голову вокруг инъекции иждивенчества. Проект Google Guice крошечный и делает DI только с чистой Java - без XML и без дополнений. Есть хорошее вводное видео, объясняющее DI тоже. http://code.google.com/p/google-guice/
Вот хорошая статья, объясняющая идеи весны. (Род Джонсон, основатель структуры Весны)
.У вас уже есть хорошие ответы, я хочу ответить на пару конкретных вопросов, которые у вас есть:
Идея описания классов со значениями сеттеров и/или параметрами конструктора мне кажется странной. Почему? Потому что мы можем изменить свойства без перекомпиляции проекта? Это все, что мы получаем?
Поначалу это кажется странным, но дело в том, что контейнер отвечает за подключение зависимостей для объектов, а сами объекты за это не отвечают. Масштабом объектов, сконфигурированных в beans.xml, управляет Spring, так что нам не нужно так беспокоиться о том, что все будет инстанциироваться без правильных зависимостей (пока конфигурация правильная, я писал юнит-тесты, чтобы проверить, что пружинная конфигурация делает то, что я хочу)
Тогда, какие объекты мы должны описать в beans.xml ? Все объекты или только несколько ?
Типы объектов, описанных в beans.xml, в основном являются компонентами - контроллеры, сервисы, объекты доступа к данным, и вещи, которые им нужны, такие как менеджеры транзакций, фабрики спящего сеанса, источники данных, и тому подобное. Объекты домена обычно извлекаются из объектов доступа к данным или инстанцируются напрямую, потому что они не имеют зависимостей ни от чего, кроме других объектов домена (или от классов утилит, которые даже более независимы, чем доменные классы)
.Я думаю, что смогу взломать вопрос, хотя не уверен, что какой-нибудь ответ будет удовлетворительным.
Легкий ответ, что Spring - это комбинация технологий:
- инъекция зависимости, которая использует принцип Голливуда, чтобы помочь вам отделить интерфейс и реализацию;
- аспектноориентированное программирование, которое изолирует перекрестные проблемы в модули, которые вы можете применить декларативно. Приветствие" AOP - это протоколирование, но это все весной (например, транзакции, динамические прокси для удаленного доступа, безопасность и т.д.) Подумайте о сервлет-фильтрах, и у вас появится идея;
- библиотеки для помощи в таких общих задачах, как персистентность (JDBC, Hibernate, iBatis, JDO, JPA и т.д.). ), удаленного доступа (RMI, HTTP, веб-службы), асинхронного обмена сообщениями (POJO, управляемые сообщениями), проверки и привязки, web MVC (Spring или Struts), утилит, таких как электронная почта, планирование, безопасность и т.д.
Но более глубокий ответ заключается в том, что вы получаете пользу от опыта Рода Джонсона как консультанта по проектам Java EE. Он перевел то, что работало на его концертах, в Interface 21/Spring, и теперь вы можете получить все это бесплатно.
Команда The Spring пишет код, который спроектирован, протестирован и следует стандартам более строго, чем что-либо, что я когда-либо напишу. (Представьте себе, как Юрген Хёллер бровит Рода Джонсона, потому что его код не соответствовал стандарту до регистрации). Я могу рассчитывать на их код фреймворка, когда использую его, и сосредоточиться на своей бизнес-задаче. Я не пишу код котельной пластины снова и снова.
Для меня весна - это скорее архитектурный шаблон, который действует как руководство по созданию веб-приложений. Некоторые люди могут сказать, что он перепроектирован, и для некоторых проблем он корректен, но для тех проблем, с которыми я сталкиваюсь на регулярной основе, весна - это всего лишь билет.
Что касается подвопросов:
Какие у нас есть преимущества при использовании фреймворков инъекций зависимостей?
Объекты не обязаны отвечать за управление своими зависимостями. Весенний контекст приложения на самом деле является всего лишь большой заводской моделью от GoF. Она поощряет вас к проектированию интерфейса, чтобы вы могли изменять реализацию по мере необходимости. Ваш интерфейс персистентности может использовать JDBC реализацию сегодня, Hibernate завтра; вы можете принять решение об автоматической генерации прокси для управления его транзакционным поведением. Ни один клиентский код не должен меняться, если вы кодируете на интерфейс.
Идея описания классов со значениями setter и/или параметрами конструктора кажется мне странной. Почему? Потому что мы можем изменять свойства без перекомпиляции Проект? Это все, что мы получаем?
Странно? Вы не используете свойства или конструкторы в своем коде? Вы делаете это потому, что так написано большинство классов Java. Весна просто использует эти механизмы как способ предоставления зависимостей классу.
Тогда, какие объекты мы должны описать в beans.xml ? Все объекты или только несколько ?
Только те бобы, которые имеют зависимости. Я все еще называю "new" для объектов, которые являются локальными для определенного метода. Они создаются, используются, и мусор собирается в области видимости метода. Они не должны быть под контролем Spring
.Opinion: Выясните, какую проблему вы пытаетесь решить с помощью DI, и возьмите фреймворк, который лучше всего подходит. Весна может добавить много сложности вашей проблеме.
(Одна из первых статей Мартина Фаулера о DI. Я думаю, что термин DI был придуман в этой статье.)
.Вот хорошее видео , предоставленное Бобом Ли и двумя его исследованиями о Гуице (Гуис - это каркас для инъекций зависимостей, как Весна). Первые 10 или около того минут рассказывают о том, почему Гус (или инъекция зависимости) был бы лучше, чем альтернатива (Фабрики), так что дело не только в Гус.
.Введение зависимости - это обходной путь для пропущенных виртуальных классов !
NB: если вы не знаете, что такое виртуальные классы, пожалуйста, обратитесь к "Виртуальные классы, кто-нибудь?" .