주니어 개발자 성장기

엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있으면, 변경 포인트가 너무 많아서, 유지보수가 어렵다! 모든 연관관계는 지연로딩으로 설정! (중요) 즉시로딩 (EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다! 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다. @XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시 로딩이므로 직접 지연로딩으로 설정해야 한다. 컬렉션은 필드에서 초기화 하자. 컬렉션은 필드에서 바로 초기화하는 것이 안전하다. null 문제에서 안전하다. 하이버..

애노테이션 직접 만들기 @Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일 시 타입 체크가 안된다. 다음과 같은 애노테이션을 만들어서 문제를 해결할 수 있다. @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Qualifier("mainDiscountPolicy") public @interface MainDiscountPolicy { } @Qualifier를 적용할 클래스에 적용 @Component @MainDiscount..

캐시와 조건부 요청 프록시 캐시 원서버와 직접 통신하는 경우 시간이 오래걸리기 때문에 프록시 캐시 서버를 통해서 자주 전송하는 데이터들을 캐싱해놓는다. private 캐시: 웹브라우저에서 사용하는 캐시 public 캐시: 프록시 캐시 서버에서 사용하는 공용 캐시 캐시 지시어(directives) - 기타 Cache-Control: public 응답이 public 캐시에 저장되어도 됨 Cache-Control: private 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본 값) Cache-Control: s-maxage 프록시 캐시에만 적용되는 max-age Age: 60(HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시내에 머문 시간(초) 캐시 무효화 Cache-Contro..

캐시와 조건부 요청 캐시 기본 동작 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 하드웨어에 비해서 매우 느리고 비싸다. 브라우저 로딩속도가 느리다. -> 느린 사용자 경험 캐시 적용 응답 헤더에 'cache-control: max-age=60'와 같은 라는 캐시 제어 헤더를 넣어준다.(캐시가 유효한 시간) 응답 결과를 캐시에 저장한다. 그 후 요청부터는 캐시 유효 시간 검증을한다. 유효 시간 이내이면 캐시에서 가져온다. 시간을 초과하면 재요청을 해야 한다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 검증 헤더와 조건부 요..

롬복과 최신 트랜드 막상 개발을 해보면, 대부분이 다 불변이고, 그래서 다음과 같이 필드에 final 키워드를 사용하게 된다. (final 키워드를 달면 생성자 호출 이후에는 변경이 불가능하다. - 상수) 하지만 생성자를 작성하는 것은 번거롭기 때문에 다음과 같은 방법을 쓴다. 생성자에 @Autowired 생략 생성자가 1개라면 생략 가능하다. 롬복의 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다. 위의 두 방법을 동시에 사용하면 깔끔한 코딩이 가능하다. 조회 빈이 2개 이상 - 문제 @Autowired는 타입(Type)으로 조회한다. 따라서 같은 타입의 Bean이 두 개가 있으면 오류(NoUniqueBeanDefinitionEx..

다양한 의존관계 주입 방법 의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 생성자 주입 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법이다. 특징 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용 *중요! 생성자가 1개 있으면 @Autowired를 생략해도 된다! * 물론 스프링 빈에만 해당한다. 생성자 주입은 스프링 빈 등록단계에서 의존 관계 주입이 함께 이루어 진다. 수정자 주입(setter 주입) setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법이다. 특징 선택,변경 가능성이 있는 의존관계에 사용 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 ..