Год назад я написал статью про DI в Spring/Java EE. Мой тезис звучал довольно категорично: "DI через конструкторы является единственно правильным. Все остальное – от лукавого". Прошло время, я пообщался с разными разработчиками на эту тему, сменил проект, компанию, провел множество собеседований, отсмотрел большое количество строк на code-review и сейчас могу сказать, что не все так однозначно. Давайте наконец разберемся, как же все-таки инжектить правильно.
Скажу сразу, что я по-прежнему считаю DI через конструкторы наиболее правильным с точки зрения поддерживаемости. Однако бывают ситуации, когда инжекты через поля оправдывают себя. Рассмотрим некоторые из них.
@PersistenceContext
Если вы работаете с базами данных в Spring, скорее всего, используете Spring Data. Это потрясающий инструмент, который упрощает взаимодействия с реляционными (и не только) СУБД на порядки. Тем не менее в сложных системах может потребоваться более низкоуровневое взаимодействие непосредственно с EntityManager. Как нам получить его инстанс? Что же, один из способов – внедрение EntityManagerFactory.
@Repository
public class TestRepository {
private final EntityManagerFactory emf;
@Autowired
public TestRepository(EntityManagerFactory emf) {
this.emf = emf;
}
@Transactional(readOnly = true)
public Set<String> findAllLastNames() {
EntityManager em = null;
try {
em = emf.createEntityManager();
List<String> lastNames =
em.createQuery("select distinct lastName from Person")
.getResultList();
return lastNames.stream()
.collect(Collectors.toSet());
} finally {
if (em != null) {
em.close();
}
}
}
}Здесь нам нужно беспокоиться о корректном открытии и закрытии EntityManager. Можно упростить себе жизнь.
@Repository
public class TestRepository {
@PersistenceContext
private EntityManager em;
@Transactional(readOnly = true)
public Set<String> findAllLastNames() {
List<String> lastNames =
em.createQuery("select distinct lastName from Person")
.getResultList();
return lastNames.stream()
.collect(Collectors.toSet());
}
}Аннотация @PersistenceContextвнедряет прокси, который выполняет открытие и закрытие EntityManager автоматически. Это вариант гораздо проще понимать и поддерживать.
Кастомные инжекты
Spring – очень гибкий инструмент. Если вдруг обычного @Autowiredвам стало недостаточно, есть возможность дополнить DI механизм новыми модулями. Предположим, что нам нужна аннотация, которая будет внедрять случайное целое число.
@Service
public class TestService {
@AutowiredRandomInt(min = 10, max = 20)
private int randomNum;
// business logic...
}Чтобы реализовать функциональность, требуется написать bean post processor.
@Component
public class AutowiredRandomIntBeanPostProcessor implements BeanPostProcessor {
@Override
@SneakyThrows
public Object postProcessBeforeInitialization(Object bean, String beanName) {
for (Field field : bean.getClass().getDeclaredFields()) {
if (field.isAnnotationPresent(AutowiredRandomInt.class)) {
AutowiredRandomInt annotation = field.getAnnotation(AutowiredRandomInt.class);
int random = ThreadLocalRandom.current().nextInt(
annotation.min(),
annotation.max()
);
field.setAccessible(true);
field.set(bean, random);
}
}
return bean;
}
}Удобно, не правда ли? Более того, мы можем сделать несколько bean post proccessors, подчиняющихся разным профилям (dev, test, prod и так далее).
Этот случай довольно простой. Но в докладе Евгения Борисова есть хороший пример, как кастомные инжекты могут помочь при работе с Apache Spark (таймкод 45:15).
Self-call при использовании Transactional
Я думаю, многие знают этот знаменитый вопрос с собеседований: "Если вызвать метод a, выполнится ли он транзакционно?"
public class MyService {
public void a() {
this.b();
}
@Transactional
public void b() {
// do something...
}
}Краткий ответ – нет. Более подробный можно найти во множестве статей на том же Хабре. Но если все же требуется выполнить a транзакционно, но поставить @Transactional над методом мы по какой-то причине не можем, self-injection выручит нас.
public class MyService {
@Autowired
private MyService testService;
public void a() {
myService.b(); // now it's transactional
}
@Transactional
public void b() {
// do something...
}
}Так как заинжектен будет прокси, который реализует управление транзакциями, вызов myService.b() так же будет выполнен транзакционно.
Хочу отметить, что это решение не является указанием к действиям. Self-inject – не есть хороший паттерн. Однако, если нам приходится поддерживать проект, который разрабатывался в течение многих лет, рефакторинг может быть чересчур дорогим. Поэтому в ряде случаев такой подход является наименьшим злом.
А как же тесты?
Одним из доводов против использования DI через поля в моей предыдущей статье был пункт, который гласил, что на такие классы нельзя написать unit-тесты. Формально это так. Но никто не отменял тесты с поднятием Spring Context. Благо c приходом Spring Boot это стало совсем просто. Вот пример теста для вышенаписанного TestRepository.
@DataJpaTest
class TestRepositoryTest {
@Autowired
private TestRepository testRepository;
@TestConfiguration
static class Config {
@Bean
public TestRepository testRepository() {
return new TestRepository();
}
}
@Test
void shouldReturnZeroResults() {
assertEquals(0, testRepository.findAllLastNames().size());
}
}Как видите, никаких проблем с тестированием функциональности не возникает. Более того, я считаю, что стандартный подход с мокированием всего и вся зачастую не эффективен и довольно ограничен. Но эта тема для отдельной статьи.
DI через поля или через конструктор?
Как я упомянул в начале статьи, DI через конструктор для меня по-прежнему остается более приоритетным. И вот почему.
Невозможность циклических зависимостей
И DI через поля, и DI через сеттеры не исключают шанса получить циклическую зависимость. Более того, когда это начнет мешать дальнейшей разработке, может быть слишком поздно что-то менять. При инжекте через конструкторы такая ситуация невозможна, ведь мы сразу получим ошибку в рантайме.
Иммутабельность
При DI через конструктор соответствующие поля можно объявить как final. Это исключает возможные ошибки при неправильных переприсваиваниях. Если вы используете Lombok, то приятным бонусом будет то, что сгенерировать конструктор можно с помощью @RequiredArgsConstructor, так как, начиная со Spring 4.3, ставить @Autowiredнад конструктором не обязательно, если он единственный.
Тестирование с моками
Как я написал выше, всегда можно протестировать бин, подняв Spring Context. Однако в некоторых ситуациях это является излишним. Обычные unit-тесты с моками выполняются гораздо быстрее и не требуют никаких дополнительных конфигураций. DI через конструкторы и сеттеры оставляют пространство для такого решения. DI через поля – нет.
Заключение
На это все с инжектами. Пока. Если у вас есть вопросы или предложения, пожалуйста, оставляйте свои комментарии. Спасибо за чтение!
