Современные рекомендации Spring (начиная с Spring 4.x) рекомендуют не использовать вставку поля (с @Autowired или @Inject), а вместо этого предпочитать аргументы конструктора. Несколько обсуждений этого здесь , здесь , а сама платформа Spring Framework рекомендует использовать DI на основе конструктора для обязательных зависимостей . В целом, я полностью согласен с обоснованием, и на самом деле я уже несколько лет не использую ни один из механизмов ввода поля.
Однако меня беспокоит то, как мы внедряем Spring Data Repositories. Конечно это обязательные зависимости, сервису нужны они для работы. Когда вы смотрите на документацию Spring Data , вы обнаруживаете, что сама справочная документация использует @Autowired внедрение полей повсеместно, именно то, что было рекомендовано как плохая практика в самой документации Spring Framework.
Конечно, нет проблем, если в репозитории используется инжектор конструктора. Я использовал это в течение достаточно долгого времени. Однако иногда компоненты и сервисы нуждаются в большом количестве репозиториев. Служба может взаимодействовать с 7 или 8 таблицами базы данных, и они должны быть в одной транзакции.
Откуда у go аккуратный код? Использование аргументов конструктора является более безопасным подходом, но приводит к огромному количеству аргументов конструктора. Внедрение сеттера, похоже, не подходит, это не дополнительные зависимости. Предполагается, что внесение поля должно быть ошибочным (хотя Spring Data использует c и использует его).
Есть ли другой подход, который можно использовать? Я испытал желание объединить связанные репозитории в отдельный @Component, по крайней мере, конструктор службы получает только один аргумент с этим конструктором. Это немного помогает, но еще сложнее взаимодействовать с новой таблицей (новый агрегат должен быть добавлен в агрегат, а службе потребуется вызывать для него геттер).
Как это должно быть сделано аккуратно, не нарушая каких-либо рекомендаций по безопасности и придерживаясь стандартов кодирования (мало аргументов конструктора и т. д. c.)?