Я читал больше о принципах Inversion of Control и Inpendency Injection как его реализации, и я уверен, что понимаю его.
Кажется, что в основном говорится «не объявляйте инстанцирования ваших учеников внутри класса». Скорее, что экземпляры должны быть переданы и назначены через конструктор; «введен» в класс из внешнего источника.
Если это так просто, как кажется, зачем нам нужны такие фреймворки, как spring или guice, которые реализуют это с аннотациями? Я что-то упустил здесь? Я действительно изо всех сил пытаюсь понять, что такое использование платформ Dependency Injection.
Изменить: О возможном дубликате, я считаю, что мой вопрос является более уникальным, поскольку он задает вопросы о каркасах DI в целом, а не только Spring. Spring - это не просто структура DI, поэтому есть много причин, по которым кто-то захочет использовать Spring, которые не связаны с DI.
Ответы:
Нам не нужны рамки. Вполне возможно реализовать внедрение зависимостей вручную, даже для относительно большого проекта.
С другой стороны, использование инфраструктуры упрощает ее, особенно основанную на аннотациях или автоматическом обнаружении зависимостей, поскольку упрощает процесс: если я решу, что мне нужна новая зависимость в классе, все, что мне нужно сделать, это добавить это в конструктор (или объявить сеттер) и объект вводится - мне не нужно изменять какой-либо код реализации.
Кроме того, платформы часто содержат другие полезные функции. Например, Spring содержит полезную среду для аспектно-ориентированного программирования, включая декларативное разграничение транзакций (что очень удобно) и множество реализаций адаптера, которые облегчают интеграцию многих сторонних библиотек.
источник
Зачем нам вообще нужен DI (Dependency Injection)?
Механизм DI отделяет производство объекта от потребления объекта. Зависимости, в которых нуждается объект, доставляются прозрачным извне. Преимущество этого механизма очевидно: вы можете в любое время обмениваться зависимостями, например, используя нулевой объект для тестирования.
Как это сделать?
Есть несколько способов достижения цели:
Нужны ли нам DI-фреймворки?
Нет, совсем нет. Вы можете просто передать все экземпляры другим объектам вручную. Если у вас небольшое приложение, вам не понадобится пружинный контейнер.
Но с другой стороны, фреймворки помогают вам в управлении объектами:
Они помогают вам установить сложные объектные отношения. Вы не должны писать шаблонный код, генерировать экземпляры и передавать их соответствующим объектам.
Они помогают вам контролировать, когда создается объект: вы можете создавать экземпляры во время начальной загрузки приложения, но в некоторых случаях ленивое создание - только при необходимости - лучше
Они помогают вам контролировать, сколько экземпляров создается: по одному на время жизни приложения или по одному на запрос (если вы занимаетесь веб-программированием)
Если ваш проект имеет подходящий размер - если вы чувствуете необходимость писать меньше стандартного кода - это полностью имеет смысл, используя (DI-) каркас. Есть больше плюсов, чем минусов.
источник
С весной это в основном вопрос удобства.
Если у вас есть класс,
TopLevel
который конструирует класс,MiddleLevel
который конструирует классLowLevel
, и вы понимаете, что вам нужен новый параметр конструктораLowLevel
, вы должны также добавить егоTopLevel
иMiddleLevel
просто, чтобы, когда пришло время дляMiddleLevel
созданияLowLevel
значения, было доступно так что это может быть передано его конструктору. С весной вы просто добавляете аннотацию.Кроме того, с помощью Spring можно определять зависимости во внешнем файле конфигурации вместо xml, и это, предположительно, дает вам возможность генерировать новую систему с совершенно другой разводкой «без изменения какого-либо кода». (ИМХО, это полностью неверно направлено, потому что изменение xml не так сильно отличается от изменения кода, и на самом деле код обычно имеет гораздо лучшую проверку ошибок и проверку типов, чем xml.)
Другое дело, что многие люди боятся конструкторов; они не понимают их, они не любят их, они предпочли бы не использовать их.
источник
MiddleLevel
, но должен получать его при конструированииTopLevel
в качестве аргумента для конструктора. АналогичноMiddleLevel
должен получитьLowLevel
в своем конструкторе.Несколько лет назад я написал программу для мониторинга веб-страниц, веб-портлетов, даже определенных таблиц базы данных, в компании, в которой я работал. Я хотел, чтобы он был достаточно гибким, чтобы пользователь мог указать, какие мониторы будут работать и с какими параметрами (URL-адреса, имена входа, критерии успеха и т. Д.). Поэтому я написал его для чтения из файла XML и использования отражения Java для создания экземпляров указанных классов и использования методов установки для установки указанных параметров.
Позже я узнал, что Spring сделает то же самое для вас, и многое другое.
Так что в моем случае я обнаружил, что
Использование структуры внедрения зависимостей помогает сделать программу гибкой и упростить определение того, как она будет работать (в рамках четко определенных параметров, конечно).
Использование стороннего DI-фреймворка избавляет вас от необходимости изобретать велосипед.
источник