Java: конструктор класса Spring Boot со слишком большим количеством DI?

Скажем, у меня есть класс Spring загрузки:Java: конструктор класса Spring Boot со слишком большим количеством DI?

public class SomeClass { 

    private ApplicationContext applicationContext; 
    private MessagingService messagingService; 
    private ClientReportFactoryImpl clientReportFactory; 
    private TerminalReportFactoryImpl terminalReportFactory; 
    private XMLView xmlView; 
    private PrepareXMLService prepareXMLService;

И у меня есть конструктор в этом классе:

@Autowired 
    public SomeClass (ApplicationContext applicationContext, MessagingService messagingService, ClientReportFactoryImpl clientReportFactory, 
                   TerminalReportFactoryImpl terminalReportFactory, 
                   XMLView xmlView, 
                   PrepareXMLService prepareXMLService) { 
     Assert.notNull(applicationContext, "ApplicationContext must not be null!"); 
     this.applicationContext = applicationContext; 
     Assert.notNull(messagingService, "MessagingService must no be null!"); 
     this.messagingService = messagingService; 
     Assert.notNull(clientReportFactory, "ClientReportFactory must not be null!"); 
     this.clientReportFactory = clientReportFactory; 
     Assert.notNull(terminalReportFactory, "TerminalReportFactory must not be null!"); 
     this.terminalReportFactory = terminalReportFactory; 
     Assert.notNull(xmlView, "XMLView must not be null!"); 
     this.xmlView = xmlView; 
     Assert.notNull("PrepareXMLService must not be null"); 
     this.prepareXMLService = prepareXMLService; 
    }

Является ли это считается плохой практикой использования, что многие зависимости в конструктор класса? Должен ли я реорганизовать мои классы, чтобы в конструкторе было всего 1-2 DI?

источник

2016-10-25 Deniss M.

Это действительно зависит от вашей общей структуры приложения. Но обычно считается, что плохая практика имеет слишком много зависимостей. Это хорошая идея часто думать о том, почему все эти услуги необходимы в одном классе. Единственный принцип ответственности - Не нужно строго следовать ему, но хорошо думать о часто. – kjsebastian

Именно по этой причине я хочу внести изменения. Я думаю, что это плохой дизайн, чтобы иметь столько DI в одном классе. Мне нужно реорганизовать и посмотреть, смогу ли я удалить некоторые из обязанностей этого класса и делегировать их где-то еще. –

Зачем вам нужны все эти зависимости в вашем классе 'Application'. Это должно быть, как правило, только для конфигурации/бутстрапа и не должно содержать логики. Похоже, вы вводите их для использования в других методах '@ Bean'. –

Вы не должны ссылаться на все ваши услуги прямо в Application классе, есть хороший путеводитель по how to structure your code (это и в следующих главах), поэтому он может выглядеть следующим образом:

com 
+- example 
+- myproject 
    +- Application.java 
    | 
    +- domain 
    | +- Customer.java 
    | +- CustomerRepository.java 
    | 
    +- service 
    | +- CustomerService.java 
    | 
    +- web 
     +- CustomerController.java

В принципе идея , что ваш Services в настоящее время annotated with attributes, как @Service (очевидно), так что они будут подняты @ComponentScan в вашем Application.

источник

2016-10-25 09:57:49 gtonic

Я спрашиваю о количестве DI в целом в классе. Класс приложения был плохим примером. Виноват. –

Я вижу. Так что единственное, что я мог сказать - из моего личного опыта не более трех инъекций на класс, иначе я бы начал думать о том, как экстернализировать эти зависимости. – gtonic

Я слышал о требовании 5. Но опять же, о ситуации, когда мне нужно запустить службу, которая могла бы использовать несколько таблиц для сбора данных. Тогда в теории я мог бы использовать довольно много репозиториев из-за сложности очередей. –

Java: конструктор класса Spring Boot со слишком большим количеством DI?

ответ

Смежные вопросы