묻고 답해요
131만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 핵심 원리 - 기본편
자동등록에서는 이 방법을 사용할 수 없나요?
@Component에서도 적용이 될까 싶어서 @Component(initMethod = "init", detroyMethod = "close") 를 해봤는데 컴파일 에러가 나네요. 이 방법은 수동 등록에서만 가능한 방법인건가요?
-
해결됨스프링 핵심 원리 - 기본편
안녕하세요!
안녕하세요~ 강의를 듣다가 궁금한 점이 생겨서 질문 남깁니다! @Bean의 initMethod, destroyMethod 속성을 사용하면 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있다고 하셨는데 외부 라이브러리 코드를 고칠 수 없는 상황에서 어떤 의미로 적용이 가능한지 궁금해서 질문 드립니다!외부 라이브러리에 이미 구현되어있는 메소드를 초기화나 종료 시 구현해야하는 메소드로 지정해준다는 뜻인가요?? 답변 주시면 감사드립니다! 또, 항상 강의 너무 잘 보고있습니다! 좋은 강의 찍어주셔서 정말 감사드려요 :))
-
미해결스프링 핵심 원리 - 기본편
@Primary방법과 @Autowired 필드명 방법 간의 우선순위
안녕하십니까 강의 항상 감사드립니다. 다름이 아니오라 생성자 주입을 사용하는 경우에 생성자의 Parameter 명을 rateDiscountPolicy로 네이밍하였고 동시에 테스트를 위해 FixDiscountPolicy 클래스 정의 위에 @Primary를 작성하여 과연 '@Primary방법'과 '@Autowired 필드명 방법'이 동시에 사용되었을 떄 어떤것이 적용 되는지 확인을 해보았습니다. 그 결과로 아무리 생성자의 Parameter명을 'Spring Container의 Bean Naming'에 따라 네이밍 했다고 하더라도 @Primary 애노테이션이 기재된 타입이 우선순위로 책정되어 OrderServiceImpl은 RateDiscountPolicy가 아닌 FixDiscountPolicy에 의존하게 되더군요 제가 아직 단위 테스트 코드 작성에 단련되지 않은터라 제가 한 테스트 결과가 맞는 것인지 여쭙고자 질문 남기게 되었습니다. 답변 부탁드립니다. 항상 현업에 바쁘신 와중에도 늦은시각 까지 강의질문 답변에 신경써주셔서 감사합니다. ^^
-
미해결스프링 핵심 원리 - 기본편
AppConfig, ApplicationContext 에 대한 질문
안녕하세요 강사님, 몇가지 질문 드리겠습니다. ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ- 질문 1. 제가 지금까지의 흐름을 맞게 이해하였는지 궁금합니다. 이전까지의 강의에서는(@ComponentScan 등장 전) AppConfig에서 @Configuration을 달았고, @Configuration에 의해 그 밑에 있던 @Bean들을 조회하여 빈을 생성하고 등록하는 방식으로 진행이 됐습니다. 테스트 코드에서 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);위 코드를 통해서 AppConfig의 빈이 등록될 수 있었고 거기에서 @Configuration을 인식하여 그 안에 있는 @Bean들을 모두 인식해 필요한 빈들을 등록하였습니다. 결론적으로, 지금까지는 어떠한 컴포넌트 스캔도 이뤄지지 않았으며 모든 빈 등록은 new Annotation~~Context(AppConfig.class)에 의해 생성된 AppConfig 빈에 의해 이루어졌습니다. 제가 맞게 이해한건가요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 질문 2. @ComponentScan을 사용한다면 ApplicationContext 가 굳이 필요없지 않나 하는 생각이 듭니다. AppConfig와 @Configuration을 통해 수동으로 빈을 등록한다 하더라도.. 컴포넌트 스캔의 범위에 AppConfig를 두면 알아서 모든 빈들이 문제없이 생성될 것입니다.(굳이 new Annotation~~Context(AppConfig.class) 를 통해 AppConfig 빈을 등록하지 알아도 알아서 스캔되어 등록될 테니까) @Component, @Autowired를 통해 의존성 주입을 해결해도 컴포넌트 스캔의 범위만 잘 설정해준다면 모든 빈들은 문제없이 생성되고 주입될 것입니다. 그렇다면 실제 프로그래밍에서는 ApplicationContext는 쓰이지 않는다고 봐도 되나요? 아니면 강의에서 해오셨던 것처럼 테스트 코드에서 getBean을 사용하기 위해서만 사용된다고 보면 될까요? 그것도 아니면 실제 프로그래밍에서도 사용되는 어떠한 용도가 있을까요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ질문 3. 다른 질문에서 지금까지 CoreApplication을 전혀 사용하지 않았기 때문에 CoreApplication 없이 프로젝트를 돌려도 똑같이 돌아갈 것이라고 말씀하셨는데요. CoreApplication에 대한 직접적인 사용은 없었지만 CoreApplication에 @SpringBootApplication이 있고 그 안에 @ComponentScan이 있고CoreApplication은 hello.core 하위에 존재하니까 hello.core 하위의 패키지를 모두 컴포넌트 스캔 할 것이고.. 그럼 CoreApplication은 컴포넌트 스캔으로 프로젝트에 영향을 미치고 있던 게 아닌가요? 어떻게 이 중요한 녀석을 빼놓고도 똑같이 동작할 수 있는 것인가요? 이에 대한 해답으로 new Annotation~~Context(AppConfig.class)를 통해 모든 빈 등록을 했으니 CoreApplication의 @ComponentScan이 없어도 되는 것인가? 라는 생각이 드는데요. 만약 이게 맞다면 하나 더 궁금해지는 것이.. 이대로라면 빈 등록이 CoreApplication의 @ComponentScan에 의해 한 번, AppConfig의 @Configuration에 의해 또 한 번. 총 두 번의 빈 등록이 일어나는데 이것에 의한 에러가 발생하지 않는 이유가 무엇인가요? 이번 실습에서 이와 같은 오류를 막기 위해 @Configuration을 컴포넌스 스캔 범위에서 제외하는 코드를 따로 작성해줬던 것이 아니었나요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 질문 4. 이전 강의에서 스프링 컨테이너가 @Configuration을 통해 싱글톤을 가능하게 하는 방법을 설명해주셨는데요.(@Configuration이 동록된 클래스를 상속받아 AppConFIg@@@CGLIB으로 사용하는 방법) 만약 AppConfig와 @Configuration이 없이 @ComponentScan을 통해서만 빈 등록과 의존성 주입을 모두 처리할 경우에는 어떤 식으로 싱글톤을 유지할 수 있게 되나요? 혹시 이게 너무 지엽적인 부분이라면 "그냥 스프링 컨테이너가 알아서 잘 해준다." 정도로 받아들이고 넘어가도 괜찮을까요? ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 지식의 소용돌이가 아직 완벽히 정리되질 않아 질문이 너무 길고 횡설수설 합네요. 죄송합니다. 강의 재밌게 잘 듣고 있습니다. 감사합니다!
-
미해결스프링 핵심 원리 - 기본편
강사님 스프링 컨테이너에 관한 질문이있습니다.
강의 내용을 복습하다가 막힌곳이 있는데 AppConfig 클래스에 Configuration 애노테이션이 있으니깐 결론적으로 스프링 컨테이너가 되고 그 이하의 Bean들을 관리해주는 건가요?? Configuration 애노테이션이 붙어있으면 붙어있는 클래스가 모두 스프링 컨테이너가 되는건가요??
-
해결됨스프링 핵심 원리 - 기본편
싱글톤이 DIP를 위반한다는 점에서 질문있습니다.
안녕하세요. 수업을 듣다가 Singleton이 DIP를 위반한다는 점에서 여쭤보고 싶은 점이 생겼습니다. 클라이언트에서 의존성을 주입받는 다고 하고, A, B 두 클래스가 있을 때 B가 A를 상속받는 Singleton이라 가정하겠습니다. 클라이언트가 생성자 주입을 받든, Setter 주입을 받든 A에 의존하게 하고, 클라이언트에 의존성을 주입하는 Config(?)가 A를 넣는자리에 B를 넣어주면 DIP 문제가 해결되는 것이 아닌가요? 어째서 Singleton을 쓰면 DIP가 위반되는지 궁금합니다
-
미해결스프링 핵심 원리 - 기본편
안녕하세요!! 영한님 향후 강의에 대한 질문이있습니다
안녕하세요 현재 1학기만 남은 졸업예정학생입니다 2개월뒤에 졸업작품으로 스프링부트로 웹사이트 개발예정이있습니다. 3학년때 스프링 ( jsp, oracle, mybatis) 으로 근본적인 이해없이 그냥 복붙으로 뚝딱뚝딱 사이트를 만들었던 경험이있는데 이번 졸업작품은 프론트단/백단 모두 혼자서 완벽히 이해하며 만들어 보는것을 목표로 하고있습니다. 제가 궁금한점은 1. 영한님의 스프링입문,기본 편 강의를 수강했고 현재 활용1편(야생형)까지 들은상태입니다. 스프링 기본편은 알려주시는것들이 너무 많은데 제가 제대로 소화하지 못하는것같아서 한번 듣기는 했지만 나중에 다시 꼭 들어야겠다고 생각하고있습니다. 제가 많이 부족한것인지는 몰라도 아직까지 선뜻 스프링부트로 사이트를 만들어 봐야지 하는 정도의 개념은 잡히지 않은것같습니다. 향후계획은 JPA기본편을 수강-> 활용1편 복습-> 그후 야생형 순서 로 가려고하는데 어느정도 강의를 듣고나서 시작해보시는걸 추천하시나요?? 2. 오픈예정인 실전MVC, db접근 등의 강의는 야생형 로드맵 까지 완료한후에 듣는것을 추천하시는건가요??? 당장 웹사이트를 만들어야하는 상황이면 JPA를 깊게 파는것보다 실전 MVC, DB 강의를 듣는것이 조금더 효율적일까요? 제가 생각하는것은 야생형 로드맵을 다 듣고나면 강의가 추가로 오픈될것같아서 그후에 듣고싶지만 빨리 여러강의를 수강하면 제가많이 부족한탓에 흡수를 못할것같아 걱정이됩니다 강의가 정말좋아서 처음으로 강사님의 모든 로드맵의 과정들을 전부듣는다는것을 전제하에 질문드리게되었습니다 ㅠㅠ
-
해결됨스프링 핵심 원리 - 기본편
클라이언트 코드란 뭘까요..?
정리하는 내용에서 클라이언트 코드라는 단어가 나오는데, 정확히 클라이언트란 무엇일까요..? client라는 단어가 사실 여기저기서 자주나오다 보니 헷갈립니다. 저는 프론트엔드 개발자라서 그런가 client 코드라고 하면, 브라우저에서 작동하는 프론트 코드가 떠올라서요.. 어떻게 이해를 하면 좋을까요? 소프트웨어 공학 관점에서 말하는 Actor, 특정 Actor(여기서는 주문을 하는 손님)에 대한 코드라고 보면 되는걸까요?
-
미해결스프링 핵심 원리 - 기본편
강의를듣다보니 궁금증이생겼습니다
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 으로하셨는대 ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 이렇게 하지 않으신 이유가 궁금합니다 이전까지는 이방법으로 했기때문에 궁금해졌습니다
-
미해결스프링 핵심 원리 - 기본편
테스트 코드 작성에 대한 질문
실무를 하다보면, 개발기간내 시간에 쫒겨 비지니스 로직 구현만 하고, 테스트 코드 작성은 미뤄두다 결국 못하는 경우가 많습니다. 강사님 강의를 듣다보면 로직 구현 이상으로 테스트 코드 작성에 시간을 할애해야 할 정도로 중요하게 얘기를 하시는걸 느낄수 있는데요. 꼭 테스트 코드를 작성해야 하는 이유를 뭐라고 생각해야 할까요? 사실, 그동안은 테스트 코드는 형식상 작성하는거다라고 우선순위를 낮춰 생각해왔거든요. 제가 잘못생각하고 있었다면 조언 부탁드립니다.
-
미해결스프링 핵심 원리 - 기본편
다이어그램 그리실때 툴은 어느거 사용하셨나요?
수업 내용에 대한 질문은 아닙니다.^^ 다이어그램이 간단해보여 업무 정리로 좋을꺼 같에요. 어느 툴 사용하셨는지 여쭤봅니다.
-
미해결스프링 핵심 원리 - 기본편
스프링과 SOLID 질문
안녕하세요 강사님, 질문 있습니다. 다형성만으로는 OCP, DIP를 위배할 수밖에 없다고 설명하시며 그에 대한 대책으로 스프링이 나온 것이라고 말씀해주셨는데요. 아마 이는 이전 강의에서 진행하셨던 @Configuration, @Bean을 통한 스프링 컨테이너에 객체를 등록하는 방식을 말씀하는 것일 거라고 생각합니다. 다만 의문점이 드는 부분은.. "스프링을 개발한 개발자들 또한 OCP, DIP 위배 문제에 대한 고민을 하였고 그 해답으로 스프링 프레임워크를 만들었다." 라고 함은.. 스프링이 등장하기 전에도 SOLID라는 개념은 존재했다는 것이겠지요? 그런데 OCP, DIP 위반 문제를 해결하기 위해 스프링을 만들었다? 그렇다면 스프링이 등장하기 전에는 어떤 방식으로도 SOLID를 모두 충족시킬 수 없었다는 말인가요? 그렇다면 저 SOLID라는 개념을 처음 제시했을 사람은.. 문제에 대한 해결책도 없이 그냥 객체지향 설계의 이상향만 제시했을 뿐인 건가요? 알쏭달쏭 하네요; 이번 강의도 잘 듣겠습니다. 감사합니다! ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ 바로 다음 강의에서 스프링 등장 이전 배경에 대한 설명이 다시 간략하게 나오네요. 스프링이 없이 OCP, DIP를 지켜가며 개발을 하다보니 배보다 배꼽이 커지는 일이 발생했고 그래서 스프링을 만들었다구요. 이로써 첫 질문에 대한 답은 해결이 되었는데.. 음.. 저 스프링 없이 SOLID를 유지하는 코딩 방식에 대한 건 너무 지엽적인 부분이겠죠??ㅠㅠ
-
해결됨스프링 핵심 원리 - 기본편
TestBean 클래스 관련 질문입니다.
ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);해당 코드를 통해서 TestBean 클래스가 컨테이너에 빈으로 등록이 되었으나,TestBean 클래스 내부의 @Autowired 어노테이션의 warning을 살펴보니 **Autowired members must be defined in valid Spring bean** 라는 경고 문구를 볼 수 있었습니다.해당 내용은, 자동의존주입을 받기 위해서는 현재 클래스 또한 스프링 빈으로 등록되어 있어야 한다는 의미로 해석했습니다. 결론은, 이러한 경고가 뜨는 이유를 잘 모르겠습니다.ide가 이 시점에 경고를 잡아주지 못하는 것인가요? 한가지 더 질문을 드리자면,TestBean 클래스에 @Configuration 애노테이션을 붙이게 되면, @Autowiredpublic void setNoBean2(@Nullable Member noBean2) { System.out.println("noBean2 = " + noBean2);}해당 코드에서 noBean2 부분에 빨간 밑줄이 생깁니다. (Could not autowire. No beans of 'Member' type found.)Member 타입의 빈을 찾을 수 없기 때문에 자동주입을 할 수 없다는 의미인데, 당연히 Member는 빈이 아니지만 왜 @Configuration 애노테이션을 붙였을 때 빨간 밑줄이 뜨는지 이유가 궁금합니다. @Autowiredpublic void setNoBean1(Member noBean1) { System.out.println("noBean1 = " + noBean1);}해당 코드 역시 @Configuration 애노테이션이 붙었을 때 noBean1에 빨간 밑줄이 뜹니다.
-
해결됨스프링 핵심 원리 - 기본편
AnnotationConfigApplicationContext 관련
AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class); 위 부분에서 AnnotationConfigApplicationContext 구현체 타입을 사용한 이유가 있을까요? 보니까 AnnotationConfigApplicationContext 타입에서만 getBeanDefinition 메서드를 사용할 수 있더라구요 그러면 AnnotationConfigApplicationContext이 ApplicationContext이 구현체인데 왜 getBeanDefinition을 못하는지가 궁금합니다. (하지만, ApplicationContext에서는 여러 구현체 중에 AnnotationConfigApplicationContext 있는것은 확인했으나 AnnotationConfigApplicationContext클래스에서는 ApplicationContext가 아닌 AnnotationConfigRegistry 구현체로 서로 다르게 명시 되어 있는 것도 궁금합니다. - 구현체는 하나의 인터페이스(하나의 부모)로만 구현한다고 알고 있습니다.)
-
미해결스프링 핵심 원리 - 기본편
static class TestBean 질문입니다
static inner class로 TestBean을 사용했는데요. static 키워드를 빼면 예외가 발생합니다. 내용을 보니 TestBean.class를 인자로 받아 스프링 컨테이너를 생성하고 인자로 받은 클래스를 빈으로 등록(생성)하는 과정에서 문제가 생기는 걸로 보입니다. 이 상황을 TestBean을 생성하려면 외부클래스(AutowiredTest)의 인스턴스가 필요한데 컨테이너에서 관리하는 정보에 없어서(AutowiredTest가 빈으로 등록되지 않아서) 외부클래스의 인스턴스를 생성할 수가 없고 그로 인해 static이 아닌 내부클래스를 생성(빈으로 등록)하지 못해 발생한 예외라 이해하면 될까요..? static이 붙었을 때는 TestBean을 컨테이너에 등록( 내부적으로 생성자 호출)할 때 외부클래스의 인스턴스 유무는 상관이 없기 때문에 문제없이 동작한다고 이해했고요. 몇 강 전부터 궁금했는데 이제야 질문드립니다. 제가 이해한 내용이 맞을까요? 혹시 잘못 이해한 부분이 있는지 궁금합니다^^ 강의는 정말 재미있게 잘 보고있습니다! 감사합니다^^*
-
해결됨스프링 핵심 원리 - 기본편
안녕하세요
스프링 입문 스프링 데이터 JPA 강의에서 Spring Data JPA에서 제공하는 Repository를 구현하고 있으면 Spring Data JPA가 자동으로 구현체를 등록 해준다. 이 말씀을 하셨었는데 AppConfig가 생성자 주입으로 전달하듯이 Spring Data JPA가 Repository를 구현하고 있는 인터페이스들을 찾아서 주입 역할을 해주고 있는건가요?? @Autowiredpublic SpringConfig(MemberRepository memberRepository){ this.memberRepository = memberRepository;}@Beanpublic MemberService memberService(){ return new MemberService(memberRepository);} 여기에서 SpringDataJpaMemberRepository를 어떻게 찾아가는지 궁금해서 질문 드립니다. (강의 보면서 SI 다니며 묵힌 갈증이 확 풀리는 것 같네요. 강의 감사히 듣고 있습니다. HTTP강의 까지 꼭 완강 하겠습니다!)
-
미해결스프링 핵심 원리 - 기본편
안녕하세요! 스프링 관련해서 질문 드립니다.
안녕하세요 영한님, 항상 좋은 강의 감사드립니다. 수업을 듣던 중 의문점이 생겨서 질문 드립니다. 결국 스프링을 사용하는 목적은 애플리케이션 개발에 필요한 기본 뼈대가 되는 기능들은 제공해 줄테니 개발자들은 비즈니스 로직에 집중하여 생산성을 높이는데 집중하자는 것이 목적이라는 생각이 드는데요. 혹시, 예를들어, 파이썬의 장고나 nodejs는 사용목적이 생산성을 높이기 위해 사용하는 프레임워크가 아닌건가요? 만약, 다른 프레임워크들도 결국 생산성을 높여준다는 것이 목적이라면, 다른 프레임워크들과 비교해서 자바의 스프링이 차별성을 갖는 점은 무엇이길래 메이저 it 기업에서 그토록 많이 사용되는 것인지 궁금합니다.
-
해결됨스프링 핵심 원리 - 기본편
AppConfig에서 MemberRepository 객체 생성에 관하여 질문있습니다.
현재 AppConfig에선는 MemberService, OrderService 둘 다 memberRepository()를 통해 MemoryMemberRepository 객체를 주입 받고 있습니다. 하지만 memberRepository()를 호출할 때마다 MemoryMemberRepository 객체가 새로 생성됩니다. 따라서 MemberService와 OrderService는 서로 다른 Repository를 참조하고 있습니다. 이렇게 서로 다른 MemoryMemberRepository를 참조해도 되는지 여쭤보고 싶습니다. 아니면 저장소인 store를 static으로 선언했기 때문에 서비스간 참조하는 객체는 다르지만 store는 공유하고 있기 때문에 상관없을까요? 아니면 추후에 서비스들이 하나의 MemberRepository만 참조하도록 하는게 나을까요?
-
미해결스프링 핵심 원리 - 기본편
싱글톤 DIP 위반에 관한 질문입니다.
이전 강의와, 이번 강의 내에서, 싱글톤 패턴을 사용하는 경우 DIP 위반이라고 말씀하셔서 질문 드립니다. 과거 강의에서 작성한 AppConfig 클래스 내부에 public MemberRepository memberRepository() { return MemoryMemberRepository.getInstance(); } 이런식으로 작성한다면, 예전에 말하셨던 Configuration(구성?) 하는 부분만 변경될 뿐, 사용하는 부분에서는 new AppConfig().memberRepository 를 하면 되는데 왜 DIP 위반이라고 하시는지 궁금해서 질문드립니다. ^_^
-
미해결스프링 핵심 원리 - 기본편
싱글톤 주의할점 강의에 대하여 궁금한 점이 있어 질문드립니다~!!
선생님~! 해당 싱글톤 주의할점에서 싱글톤은 무상태로 유지해야한다고 하셨습니다. 때문에 강의에서 지역변수 userAprice 와 userBprice를 만들어서 처음에 입력된 userAprice에 입력된 값이 출력되도록 변경하셨는데, 이게 현재 user가 2명이어서 괜찮았지만 만약에 정말 1초마다 5만명씩 유저가 가격을 입력한다면, 지역변수를 순간적으로 5만개씩 만들어서 처리하는 건지, 아니면 다른 방법으로 해당 사항을 해결하는 건지 궁금합니다 !! (공유객체의 참조와 지역변수의 관계에 대하여 조금이해가 않되서 질문드립니다. ㅠㅠ)