공부의 발자취를 남기는 블로그

@ModelAttribute?? @ModelAttribute는 요청받은 개체 속성들을 받은후, 추상화된 개체로 모델을 만든뒤 HTML파일로 자동으로 알아서 반환해준다. -> 말로하니 느낌이 확 안 와닫는다. ModelAttribute의 특징을 제대로 알려면 우선 @RequestParam과 비교를 한번 해보자. @RequestParam으로 요청받아내기 객체 Item 에 존재하는 속성 3개 itemName,price,quantity 3 요소를 받는요청이다. @RequestParam을 사용하면 그림과같이 Item에 존재하는 모든 속성을 모두 작성하고 모델에 집어넣어야한다. 이건 간단한 객체라그렇지, 실제 실무처럼 속성이 10개가 넘어가면 파라미터단락이 아주 길어질것이다. 이걸 조금 더 간결하고 스마트하게 줄여..

로그가 대체 무엇이며 왜쓸까? 로그는 스프링 프로젝트를 만들고 실행을 해보면 바로 볼 수가 있다. 로그는 다음과같이 날짜 , 중요도 , 발생한 위치 , 내용 순으로 찍어준다. 이 로그는 디버깅할때 코드 중간중간에 넣어서 확인용으로 쓰이거나 요청메시지를 찍고싶을때 쓴다. 근데 이런 비슷한 성질을 가지는 명령어가 하나 떠오르는데 바로, System.out.println() 이다. 자바에서 출력문을 볼때 정말 많이 썻던 것이다. 둘이 비교를 한번해보자. 두줄씩 써봣다. print 문과 log문이다. 그렇다. print문은 딱 내용만 보여준다. 이것이 문제가되는이유는 만약 서버에서 Error가 떳으면 그 Error 가 언제 , 어디서, 무슨내용이 터진지 알아야한다. print문은 딱 '내용'만 알려주니 정보가 ..

영속 컨텍스트란? 엔티티매니저 (Entity Manager)가 엔티티를 영구 저장하는 환경을 말한다. 영속 컨텍스트는 2가지의 저장소가 존재한다. 1. 1차캐시 저장소 2. 쓰기지연 SQL 1차캐시 저장소 Entity 를 persist()를하면 그림과같이 1차 캐시에 저장된다. 만약, 여기서 find() 조회가 일어난다면 DB에서 조회를 하지않고, entityManager에있는 1차캐시에 조회를 실시한다. 조회할 데이터가 1차캐시에 없다면 DB에서 조회를한다. DB에서 조회를한 데이터를 1차캐시에 다시 저장해두고 반환을한다. -> 나중에 또 다시 같은데이터를 조회할때 1차캐시에서 바로 반환하기위함이다. ---> 이 특징때문에 같은 Entity를 조회해도 동일성이 보장이된다. 2. 쓰기 지연 SQL 저장소..

스코프 (Scope) 란?: 말그대로 범위 다. Bean에다가 스코프를 설정한다면, Bean이 영향을 끼치는 범위를 설정해준다. 스코프의 종류 Singleton (default) ProtoType request session aplication websoket ... 등등 존재한다. 싱글톤은 스코프 설정을안했을때 기본적으로 제공되고 범위는 스프링 컨테이너 시작 ~ 스프링 컨테이너 종료 까지 미친다. 프로토타입 스코프는 싱글톤과 반대되는 개념이다. ->싱글톤은 객체가 단 하나 생성되는걸 보장한다면, 프로토타입은 요청이 들어올때마다 새로운 객체를 생성한다. ->프로토타입 객체의 범위(Scope)는 스프링 컨테이너 시작~ 스프링 컨테이너 의존관계주입 까지 미친다. 하지만 이런 프로토타입은 실제론 잘 쓰이지 않..

스프링 빈에게도 LifeCycle(생명주기)가 존재한다. 이번 포스팅은 그 생명주기를 살펴볼 것이다. 생명주기를 살펴보기위해, 각 구간마다 로그를 남겻다. 1.빈을 생성할때 [NetworkClient() 메소드] 2. 서비스(빈)가 시작할때 먼저 부르고싶을때 [ connect() 메소드 ] 3. 서비스(빈)가 기능할때 [ call() 메소드] 4. 서비스(빈) 종료시 수행하고 싶을때 [ disconnect() 메소드 ] 스프링 컨테이너를 생성한뒤, 스프링컨테이너를 닫아보겠다. NetworkClient를 수동등록을 하였는데, 주목해야할 부분은 initMethod 와 destoryMethod 이다. initMethod는 빈의 생성자가 모두 생성된후 호출하고싶을때 사용한다. destoryMethod는 빈이 종..

빈을 생성하다보면 하나의 타입에 여러개의 빈이 필요로하고, 조회하고 싶을때가 있다. 예를들어, 타입으로 지정된 빈들인 자장면, 탕수육 ,짬뽕 빈을 조회하고 싶을때나 타입으로 할인정책 빈들인 고정할인, 비율할인 빈들을 조회하고 싶을때 종종있다. 이럴경우, Map 또는 List를 활용해서 조회하면 편리하다. 코드로 한번 작성을 해보자면 1.우선 해당 타입인 빈들만 조회시키는 하나의 기능 클래스를 만듭시다. @ReauiredArgsConstructor로 생성자 주입을 하나 만듭시다. 필드로 Map 하나를 설정했는데 Key값으로는 bean이름을 받을것이며, Value값으로는 조회된 빈의 구현체를 받을겁니다. 주입을 받은 구현체는, Map에 저장이될것이고, 우리는 discount()메소드로 필요할때 뽑아쓸겁니다...

스프링에서 빈을 생성하다보면, 중복 조회대는 경우가 종종있다. 예시를 하나 들어보자. 평소에 이용하는 할인정책 1번과 가끔 이벤트 성으로 쓰는 할인정책 2번이 동시에 Bean을 등록하면 어떡할까? 잘 설계된 스프링 구조는 Interface 할인정책을 호출을하면, 1번과 2번 할인정책이 동시에 호출이된다. 스프링은 1번 할인정책을 사용할지? 2번 할인정책을 사용할지 몰라서 오류를 뱉는다. 이걸 해결하는 방법이 3가지가 존재한다. 1. @AutoWired 파라미터 이름 설정 2. @Quilfier 사용 3. @Primary 사용 1. AutoWried 파라미터 이름 설정 DiscountPolicy의 파라미터를 rateDiscountPolicy로 직접 선언해주는방법이있다. @AutoWired는 탐색하는 순서가..

이번에 자바 스프링에서 쓰이는 롬복 (lombok) 라이브러리 를 알아보겠습니다. 롬복을 쓰는 이유 객체안에 수많은 필드에 대해 Getter, Setter, 생성자를 자동입력하다보면, 너무 많은 getter,setter,생성자 코드가 생성되며 실제로 기능적인 코드를 보기 피곤합니다. 필드가 단 2개인데도, 이정도의 길이입니다. 필드가 5개 , 10개가 넘어가면 실제로 찾고싶은 기능이 밑으로 묻힐수밖에 없습니다. 찾으려고하면 또 매우 피곤하고요. 여기서 Annotation으로 아주 간단하게 줄여버리는 Lombok이 등장합니다 Annotation 3개 Getter, Setter, RequiredArgsConstructor 단 3개만으로 앞서 본 코딩과 동일한 기능을 지원합니다. lombok은 이런 반복적인 ..

스프링 @AutoWired 주석을 통해 넣을수 있는 방법은 4가지가 존재합니다. 1.생성자 주입법 2.수정자 주입법 (setter) 3.메소드 주입법 4.필드 주입법 1.생성자 주입법 앞으로 소개할 4가지 주입법중 가장 쓰기 좋은 생성자 주입법이다. 생성자 주입법의 특징: 1. final 변수를 사용할수있다. -> 바꾸고 싶지않는 의존관계,구조를 불변성을 부여할수있음. 2. 단위 테스트하기 편하다. 3. 순환 참조를 막을수있다. -> 순환참조를 하면 StackOverFlow가 발생하는데, 그걸 방지할수있음. 2. 수정자 주입법 수정자 주입법이 필요할때가 존재하긴한다. MemberRepository, DiscountPolicy 같은 Interface를 선택, 변경할때 사용한다. 만약에, 불변성을 가진 의존..

빈을 등록하는데는 크게, 수동등록 (@Bean)과 자동등록(@Component, @Autowired)가 있다. 먼저 수동등록 하는법을 알아보겠다. 수동등록은, @Configuration주석이 있는 class 안에다 @Bean주석이 들어간 메소드를 넣으면 된다. 사용자가 직접 Bean을 넣어주는거니 스프링컨테이너의 Bean수동등록이라고 한다. 하지만, 수동등록을 하나씩 넣다보면, 몇개 실수로 누락하기도 하고, 일일이 찾아서 받아쓰기도 번거롭다. 이런 불편한점을 없애기위해 탄생한 @Component와 @Autowired을 이용한 자동 빈 등록이다. @Configuration과 @ComponentScan으로만 사용하면, 자동등록이 끝난다. 자동등록을하려면, 넣을 빈을 담아야하는데, 자동등록에서 빈을 넣기위해서..