Внедрение зависимости в Spring с использованием аннотаций - PullRequest
Новая
       70

Внедрение зависимости в Spring с использованием аннотаций

0 голосов
/ 18 декабря 2018

Основная концепция внедрения зависимостей - насколько я понимаю - это практика «проектирования интерфейсов», чтобы сделать зависимые компоненты слабо связанными друг с другом.Однако я видел много систем, разработанных с использованием Spring, которые, по моему мнению, нарушают эту концепцию [а Spring Container позволяет это делать на уровне синтаксиса].Я начинаю подвергать сомнению мои знания / понимание внедрения зависимостей как концепции после просмотра такого кода / реализации.

Я регулярно вижу компоненты, автоматически подключаемые друг к другу с их конкретной реализацией, пример того, что я имею в виду: 

@RestController
public class MyRestController {
    @AutoWired
    private MyServiceOne serviceOne;
    // .. rest of the code if the rest controller here ...
}
@Service
public class MyServiceOne {
    @Autowired
    private MyRepository repo;
    // rest of code of the service here
}

Как видите, MyServiceOne - это конкретный класс, а не интерфейс, и Spring Framework с этим согласен.В классе «@Configuration» не нужно указывать метод «@Bean», чтобы внедрить правильный конкретный тип класса [поскольку @service уже является конкретным классом].

Таким образом, для любых изменений / настроекна сервисном уровне [введенная зависимость в контроллере] мне придется изменить следующую строку в контроллере: 

@AutoWired
private MyServiceOne serviceOne; //change this to be another service class, or a service class that extends it

, и это НЕ слабая связь![или это?] по моему мнению, если мы собираемся использовать Spring DI таким образом, лучше НЕ использовать его вообще!множество зависимостей maven / Gradle и объектов времени выполнения создаются в памяти приложения!

Мне интересно, что-то не хватает в моем понимании того, как Dependency Injection представляет собой концепцию / или как Spring HandleИнъекция зависимости?

ценим ваше руководство!

1 Ответ

0 голосов
/ 18 декабря 2018

Использование интерфейса обычно является наилучшей практикой, и вы, как правило, предпочитаете его в своем собственном коде (наряду с внедрением в конструктор вместо этого внедрения в поле), но быть абсурдным пуристом в отношении того, что разрешено, будет контрпродуктивно.

Например, я работаю с Amazon DynamoDB и мне нужно внедрить экземпляр класса DynamoDB.Я действительно предпочел бы иметь возможность внедрять интерфейс, но Amazon SDK не предоставляет его, и возможность внедрять настроенный экземпляр класса все же намного лучше, чем ничего не вводить.

Точно так же,в Spring Boot нередко вводить @ConfigurationProperties bean-компоненты, которые в основном являются структурно-подобными POJO без логики.В этом случае определение интерфейса было бы просто пустой тратой времени, но возможность внедрения бинов по (конкретному) типу чрезвычайно полезна.

...