해결된 질문
작성
·
296
·
수정됨
0
@Configuration(proxyBeanMethods = false)
static class MyConfig {
private final Common common;
public MyConfig(Common common) {
this.common = common;
}
@Bean
public Bean1 bean1() {
System.out.println("bean1 생성자");
return new Bean1(common);
}
@Bean
public Bean2 bean2() {
System.out.println("bean2 생성자");
return new Bean2(common);
}
}
@Configuration(proxyBeanMethods = false)
static class MyCommonConfig {
@Bean
public Common common() {
return new Common();
}
}
과
@Configuration(proxyBeanMethods = false)
static class MyConfig {
@Autowired
private Common common;
public MyConfig() {
}
@Bean
public Bean1 bean1() {
System.out.println("bean1 생성자");
return new Bean1(common);
}
@Bean
public Bean2 bean2() {
System.out.println("bean2 생성자");
return new Bean2(common);
}
@Bean
public Common common() {
return new Common();
}
}
빈 구성 정보를 프록시 객체로 생성하지 않는다는 대안을 코드로 작성해보면
별도의 구성 정보를 사용하는 방식과
내부에서 필드 주입으로 초기화 하는 방식이 생각났습니다.
별도의 구성정보를 사용하면 어떤 클래스를 의존하는지 생성자를 보고 확인할 수 있다는 장점과 테스트 코드를 작성할때 더 편할거라 생각이 들고,
밑에 방식은 Common이라는 클래스가 MyConfig 에서만 사용된다면 관리하기도 편할거라 생각이 들었습니다. 그리고 설정 정보 클래스니까 굳이 생성자로 초기화를 하지 않아도 되지 않을까 라는 생각도 들었습니다.
강사님께서 Config 클래스도 테스트를 해봐야한다고 말씀해주셨는데
이런 경우라면 상황에 따라 선택해야하는 부분인가요 ?
아니면 설정 정보도 환경에 따라 다를 경우가 있느니까 별도로 분리하는게 나을까요?
답변 2
1
같은 클래스 내에서 정의된 빈을 의존하는 다른 빈이 존해하는 경우엔 디폴트인 프록시 방식을 쓰는게 낫겠네요.
두번째 방식이라면 common빈을 만들기 위해서 MyConfig 오브젝트가 먼저 만들어져야 하는데, common을 가져올 때까지 @Autowired도 적용을 못할텐데 이게 동작할지 모르겠네요. Proxy를 안 쓰면서 굳이 같은 클래스에 넣으려면 common 빈은 static 메소드로 만들어야 할 겁니다.
첫번째 방식으로 분리하거나 common 오브젝트를 다른 @Bean 메소드의 파라미터로 주입되도록 하는게 나을 것 같기도 하고요.
0
안녕하세요, 인프런 AI 인턴입니다.
해당 내용과 유사한 질문과 강사님의 답변이 있는 게시글을 찾았습니다.
강사님께서는 JdbcTemplate과 JdbcTransactionManager의 적용 순서에 대해 언급하시며, 스프링 부트에서는 정석적인 방법을 따르기보다는 편의상 하나의 구성 정보에 넣는 경우가 있다고 설명하셨습니다. 그러나 자동 구성의 순서가 중요한 경우가 있어서, 이를 위해 @AutoConfiguration 애노테이션의 before, after 항목을 사용하여 순서를 지정할 수 있다고 말씀해주셨습니다.
이와 관련된 더 자세한 설명은 아래 링크에서 확인할 수 있습니다.
위 내용과 더불어 Config 클래스의 테스트 필요성에 대해서도 동일 게시물에서 설명이 되어있으니 함께 참고하시면 좋을 것 같습니다.
답변 감사합니다.
질문을 올리고 생각해보니 두번째 방식으로 작성할 이유가 없다는걸 느꼇네요 :(