쓰는 이유는 그냥 편리해서임. Bean으로 만들어서 알아서 넣어주는거 안하면 진짜 손가락 개박살남
익명(220.94)2024-01-12 19:21
의존성 주입은 도구니까, 그 도구가 뭘 하려는지 목적을 알아야지.
익명(211.114)2024-01-12 18:57
MetaFibonacci(equivalence)2024-01-12 19:11
해보몀 되지
익명(dcin4th)2024-01-12 19:25
쓰다보면 없으면 못 산다
익명(175.124)2024-01-12 19:32
근데 간단하게 만들거면 의존성 주입 의미없긴함.
스프링 환경에서는 의존성 주입 툴이 워낙 쉽고 직관적으로 되어있어서 의존성 주입을 하든 안하든 거의 코드짜는비용이 비슷해서 그렇지.
근데 IoC컨테이너 DI없는상태에서 추상화시켜서 의존성 주입시키는 패턴을 한다?
그럼 굳이 의존성주입 왜하냐 라는 소리나옴.
익명(211.209)2024-01-12 19:53
답글
돌이켜서 생각해보면, 의존성 주입으로 다 구성해봤자 도움받는 부분은 한정적임.
예를들어, 비즈니스 로직의 외부에있는 것들을 다루는 경우(써드파티, 영속성객체) 의존성 주입이 도움많이됨. 테스트할때도 도움되기도하고..
혹은 전통적으로 코드의 전략 자체가 자주 바뀌는 부분이 있다면 그것도 DI 해놓으면 도움되긴하는데,
솔직히 말해서 전략별로 추상화를 해놓는 비용도 무시못해서 (A전략과 B전략의 인터페이스를 하나로 맞추는 과정). 크게 도움받는 다는 느낌은 없음.
스프링 쓰면 그런거 코드 몇줄로도 쓱 할 수 있으니까 해놓는거지 머 ㅋㅋㅋ;;
익명(211.209)2024-01-12 19:58
테스트도 있지만 제일 큰거는 기능확장하거나 수정할때임
익명(49.169)2024-01-12 20:01
테스트라고 하는애들 특징이 합리적인 이유도 없이 무지성으로 테스트가 용이해진다고 모범답안만 주입식으로 외웠을듯 ㅋㅋㅋ
익명(60.253)2024-01-12 20:26
김영한 스프랑강의 보면 스프링없이 애플리캐아션 먼저만듬.
그때는 외부애서 의존성을 주입해주기위해 직접 별도 클래스를 만들어서 객체들을 상글톤으로 생성 + 주입까지 해줘야함. 그게 상당히 번거로운데 스프링은 자동으로 해주니 편안
익명(223.38)2024-01-12 20:46
보통 코드의 유연함과 확장성을 갖추기 위해 의존성 주입을 함. 가지고 있는 의존 객체를 자기 객체 내부에서 직접 생성하면, 컴파일 타임에 고정되지만, 생성자를 통해서든 뭐든 의존 객체를 외부로부터 주입받으면, 인터페이스를 활용하여, 필요할 때마다 다른 타입의 객체로 유연하게 바꾸어 런타임시 재사용 가능하기 때문에.. 근데 굳이 그런 확장성과 유연함이 필요없는 기능을 만드는 데는 더 번거롭긴 하지. 그래도 스프링에서는 왠만하면 DI를 하는 게 좋은 게, 애초에 DI 를 하라고 만든 프레임워크이기 때문에, 그 과정에서도 코드 몇 줄로 구현할 수 가 있어서, 번거로운 것도 별로 없슴. 그러니 굳이 왜 안 함? 이런 거지
ㅉ(222.109)2024-01-12 20:53
당장 스프링 di 안쓰면 콘트롤러 서비스 레파지토리 전부
직접 객체생성하고 싱글톤 유지되도록 직잡 코드다짜야되는데
스프링안쓸거임?
테스트요
별로 안중요함
쓰는 이유는 그냥 편리해서임. Bean으로 만들어서 알아서 넣어주는거 안하면 진짜 손가락 개박살남
의존성 주입은 도구니까, 그 도구가 뭘 하려는지 목적을 알아야지.
해보몀 되지
쓰다보면 없으면 못 산다
근데 간단하게 만들거면 의존성 주입 의미없긴함. 스프링 환경에서는 의존성 주입 툴이 워낙 쉽고 직관적으로 되어있어서 의존성 주입을 하든 안하든 거의 코드짜는비용이 비슷해서 그렇지. 근데 IoC컨테이너 DI없는상태에서 추상화시켜서 의존성 주입시키는 패턴을 한다? 그럼 굳이 의존성주입 왜하냐 라는 소리나옴.
돌이켜서 생각해보면, 의존성 주입으로 다 구성해봤자 도움받는 부분은 한정적임. 예를들어, 비즈니스 로직의 외부에있는 것들을 다루는 경우(써드파티, 영속성객체) 의존성 주입이 도움많이됨. 테스트할때도 도움되기도하고.. 혹은 전통적으로 코드의 전략 자체가 자주 바뀌는 부분이 있다면 그것도 DI 해놓으면 도움되긴하는데, 솔직히 말해서 전략별로 추상화를 해놓는 비용도 무시못해서 (A전략과 B전략의 인터페이스를 하나로 맞추는 과정). 크게 도움받는 다는 느낌은 없음. 스프링 쓰면 그런거 코드 몇줄로도 쓱 할 수 있으니까 해놓는거지 머 ㅋㅋㅋ;;
테스트도 있지만 제일 큰거는 기능확장하거나 수정할때임
테스트라고 하는애들 특징이 합리적인 이유도 없이 무지성으로 테스트가 용이해진다고 모범답안만 주입식으로 외웠을듯 ㅋㅋㅋ
김영한 스프랑강의 보면 스프링없이 애플리캐아션 먼저만듬. 그때는 외부애서 의존성을 주입해주기위해 직접 별도 클래스를 만들어서 객체들을 상글톤으로 생성 + 주입까지 해줘야함. 그게 상당히 번거로운데 스프링은 자동으로 해주니 편안
보통 코드의 유연함과 확장성을 갖추기 위해 의존성 주입을 함. 가지고 있는 의존 객체를 자기 객체 내부에서 직접 생성하면, 컴파일 타임에 고정되지만, 생성자를 통해서든 뭐든 의존 객체를 외부로부터 주입받으면, 인터페이스를 활용하여, 필요할 때마다 다른 타입의 객체로 유연하게 바꾸어 런타임시 재사용 가능하기 때문에.. 근데 굳이 그런 확장성과 유연함이 필요없는 기능을 만드는 데는 더 번거롭긴 하지. 그래도 스프링에서는 왠만하면 DI를 하는 게 좋은 게, 애초에 DI 를 하라고 만든 프레임워크이기 때문에, 그 과정에서도 코드 몇 줄로 구현할 수 가 있어서, 번거로운 것도 별로 없슴. 그러니 굳이 왜 안 함? 이런 거지
당장 스프링 di 안쓰면 콘트롤러 서비스 레파지토리 전부 직접 객체생성하고 싱글톤 유지되도록 직잡 코드다짜야되는데 스프링안쓸거임?