[질문] DI 라는게 결국 진짜 의미있는거야??

[익명(39.7)]

그놈의 느슨한 의존관계 결국 xml configuration  안쓰면 @Autowired 떡칠해서 구현체에 의존하게 되는데 그럼 최초에 의도는 안남아있는거 아녀?

물론 싱글톤으로 유지를 편하게 해주는것도 크고 AOP하기 쉬운것도 맞는데 DI컨테이너라기엔 이제 의미가 퇴색된거 아니냐는 거지

그리고 구현체를 일괄 변경하는것도 요즘 IDE잘나와있어서 버튼딸깍으로 되는데 의미가 있을까

- dc official App

[익명(37.120)]

DI는 오브젝트 라이프 사이클 관리해주는거 아님?

[익명(183.102)]

autowired가 왜 구현체에 의존한다는 지도 모르겠고.. 따로 configuration 파일만 잘 설정해두면 프로필 딸칵 한번으로 구현체 싹다 바뀌잖아

[익명(183.102)]

로컬이랑 스테이징서버에서 떠야하는 구현체가 다르면 매번 서버들어가서 코드 수정할거 아니잖아. di 설정만 잘해두면 그냥 프로필만 바꾸면 구현체도 바뀌게 만들 수 있는고고

[익명(183.97)]

!!! 그럼 어노테이션 기반보다 XmlConfiguration이 장점이 있네 빌드없이 재시작만으로 되니까,내가말하는건 설정파일을 많이 안쓰고 대부분을 어노테이션으로 때우고 Autowired 사용하는 경우 말한거였는데, 그런데 요즘도 XML으로 설정해?? - dc App

[익명(183.97)]

아 너가 말한건 굳이 xmlconfig 할필요없는거구나, 그냥 로컬용 config파일과 스테이싱서버용 파일을 구분해서 작성해놓고 갈아끼워가면 용도에 맞게 쓴다는거지?? - dc App

[익명(183.102)]

XML은 너무 번거롭고 읽기 힘들어서 자바 코드 내로 끌어들인게 @Confgiruation, @Bean 어노테이션 관련된 것들 인거임. 여기에 @Conditional이나 @Profile 같은거 붙여서 모듈 의존성, 프로필에 따라 구현체를 갈아끼울 수 있는거고. 이걸 좀더 보편적으로 추상화+간단화한게 스프링부트 Auto Configuration인거. 구성만 잘해놓으면 프로필, 모듈 의존성에 따라 알아서 구현체가 갈아끼워지면서 로드가 되는거지 아무튼 Autowired는 별로 권장하지 않고 생성자 주입 추천하는거도 이런 이유임. @Autowired는 니말대로 구현체에 종속되기 쉬워서 외부에서 어떤거 주입할지 '선택'하기가 어려움. 반면 생성자는 직접 선택해서 주입할 수 있으니까 경우에 따라 갈아끼우기도 쉬운거고

[익명(183.102)]

xml config이든 자바 @Configuration이든 한 군데서 설정, 주입을 관리할 수 있다는게 좋은거임. 각 파일들어가서 구현체 바꿔끼는건 찾기도 힘들고 번거로우니까

[익명(doslim)]

니가 말하는건 특정 라이브러리/프레임워크의 DI 구현체에 대한 의문 같고 일반적인 DI 패턴은 좋지

[익명(223.38)]

di 없이 개발을 해봐야 칵 - dc App

[익명(139.180)]

DI프레임워크없이 개발해나가면서 직접 DI 짜고있는 자신을 발견하는 경험을 해보면 됨

[ㅇ(211.209)]

애초에 DI가 단순한 생성자 주입과 메소드 주입이랑 구분되는 게 런타임에 설정에 따라서 인터페이스에 대응되는 객체가 주입된다는 거인 걸루암. Autowired가 구체 클래스 의존한다는 거랑 완전히 다른 이야기인듯