문제 @Getter @Entity @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Member { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private String email; } 위의 경우에는 name과 email 필드는 그저 평범한 문자열 데이터를 저장하는 역할만 수행하고 데이터의 검증이나 추가적인 처리는 포함하지 않고 있기 때문에 이를 위한 로직이 필요하다. 그렇다면 이러한 로직은 어디에 위치하는 것이 좋을지 생각해 보면 당장은 엔티티에 추가하는 것만 생각이 난다. 하지만 name과 email에 대한 로직이..

개요 스프링을 처음 배우면 누구나 IoC와 DI에 대해서 학습을 하지만 작성자처럼 개발자가 개발에만 집중할 수 있게 하기 위해 객체의 생성과 관계 설정 같은 번거로운 작업들을 컨테이너에 떠넘기는 것 혹은 이와 비슷하게 개념적으로만 그런가 보다 하고 넘어가는 일들이 많은 거 같다. (아님 말고...) 그래서 스터디에서 발표도 준비할 겸 토비의 스프링을 다시 정독하면서 DI가 무엇이고, 왜 필요한지, 적용함으로 얻을 수 있는 이득 등에 대해 최대한 간단하게 살펴보려 한다. (쓰다 보면 길어질 수도 있다) 객체 스스로 사용할 객체를 선택하고 생성하는 것이 맞을까? 클라이언트의 주문에 대한 처리를 담당하는 주문 서비스 객체의 관심사는 무엇일까라고 생각하면 당연히 요청에 맞게 주문을 처리하는 것이다. 하지만 만약..

정의 N + 1 보다는 1 + N이라고 볼 수 있는데 한 개의 쿼리에 예상과는 다른 N개의 추가 쿼리가 발생하는 문제다. 원인 즉시로딩, 지연로딩, 연관 관계와 상관 없이 언제든 N + 1 문제가 발생할 수 있다 즉시로딩의 경우 N:M 관계에서 N을 조회하는 쿼리를 날렸을 때 M을 즉시로딩으로 가져오게 되어있다면 N을 조회할 때 M을 한 번의 쿼리만 날려서 조회할거라 예상할 수 있지만 JPQL은 N을 먼저 조회하는 쿼리를 날린 후에 M을 즉시로딩으로 가져오게 설정된걸 확인하고 M을 가져오는 추가 쿼리를 날리게 된다. 일대일 관계라면 쿼리가 한 번이 아닌 2번 발생할 것이고 일대다 관계라면 1 + M개만큼의 쿼리가 발생한다. 지연로딩의 경우 N:M 관계에서 N을 조회한 후에 지연로딩으로 가져온 M의 객체들..

Mapped Diagnostic Context 멀티 쓰레드 환경에서 로그가 뒤섞이는 문제를 해결하기 위해 사용할 수 있는 객체로 현재 실행 중인 쓰레드에 메타 정보를 넣고 관리하는 공간이다. 내부적으로 쓰레드 로컬을 사용한다. Map 형태로 구성되어 (키, 값) 형태로 값을 저장하고 사용할 수 있다. 다양한 데이터를 저장해 구체적이고 유용한 로그 메시지를 제공할 수 있다. 주로 각각의 요청에 대한 로깅을 구분하기 위해 고유한 요청 ID를 설정하거나 사용자 정보, 세션, 트랜잭션, 로깅 수준 등을 설정한다. MDC 사용 implementation 'org.springframework.boot:spring-boot-starter-logging' 위의 디펜던시를 추가하면 org.slf4j 패키지에 있는 MDC..