JVM

There's no strict stnadard naming convention in SpringBoot, Howevere there's some best practice. Controller Layer The methods in the controller should be named based on the HTTP method. getUser postUser deleteOrder Service Layer Methods in service layer should be descriptive and prefixed with a verb createUser() updateUser() deleteUser() Persistence Layer Methods in persistence layer named data ..

문제 SpringBoot 를 사용한 프로젝트 중 HttpServletRequest 를 받아와 헤더 정보를 출력하는 코드에서 제목과 같은 에러를 만났다. import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import lombok.extern.slf4j.Slf4j; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; @Slf4j @RestController public class LoggingController { @GetMapp..

개요 데이터를 전달용 오브젝트 Why to use 서버 - 클라이언트간 객체를 전달할 때 메소드 콜(주로 데이터 가공)을 줄이기 위해 View 는 보통 변경이 잦은데, 이때 Entity 를 받아선 DB Schema 영향에 직격타다. 따라서 DTO를 별도로 정의해서 전달하는게 국룰이다. When to use 서로 다른 많은 오브젝트가 존재하고, 프레젠테이션 모델이 한번에 그 데이터를 전달하려 할 때 DTO를 통해 도메인으로부터 클라이언트가 필요한 데이터만 전달할 수 있게함. Where to place? 주로 서비스 레이어 -> 컨트롤러 객체로 DTO를 전달한다. 역방향(컨트롤러 -> 서비스)의 경우에는 VO (불변객체) 를 사용한다. 개발자마다 다르지만DTO는 서비스 패키지, VO는 컨트롤러 패키지에 담는..

Database 와 Object 간에는 기본적인 패러다임 차이가 존재한다. Database 관점 슈퍼타입 - 서브타입의 논리 모델이 존재한다. 이를 물리 모델로 구현할 수 있는 여러 전략이 존재한다. Joined Table 전략 Single table 전략 Table per class 전략 1. Joined Table 전략 슈퍼타입 테이블을 만들고 각각의 모든 서브타입 테이블을 별도로 생성하는 구조. Item 슈퍼타입 테이블에 별도의 `data_type` 컬럼을 두어 해당 테이블에서 어느 서브타입 테이블을 가리키는지 구분한다. 가장 정규화된 방식으로 저장 공간이 효율화됨. 정석적인 방법으로 JOIN 으로 인해 성능 저하 위험 존재한다고는 하나, 미미함. (JOIN을 잘쓴다면) 부모 - 서브타입 테이블에 ..

요구사항 가정 회원당 무조건 하나의 락커 를 점유한다. 락커 또한 무조건 한명의 회원만 사용할 수 있다. 테이블 설계 1:1 관계가 성립해야한다. 그러나 부모 자식 관계가 성립해야하고 외래키는 존재해야한다. JPA Entity class 설계 단 1:1로 살아있는 테이블을 만든다고 하면 1:1 연관관계 설정 (@OneToOne) 필요하다. 주 대상 테이블 || 대상 테이블에 외래키와 UNIQUE 제약조건을 건다. (그래야 1:1이 제대로 성립한다.) FK를 회원에 둘 것인가 사물함에 둘 것인가? 나라면 이렇게 설계하겠다. 회원에 사물함 아이디를 FK로 보유한다. 엔티티 클래스에서는 연관관계 주인으로 삼는다. 테이블 설계상으로나 비즈니스 로직상으로나 사물함으로부터 회원을 조회하기보다 특정 회원의 사물함을 ..

기본키 생성 전략에 따른 JPA 의 기본 동작 차이. IDENTITY IDENTITY 전략에서는 PK (auto_increment) 값이 Insert 쿼리가 DB에 COMMIT 되는 시점에 확정된다. 문제 상황 영속성 컨텍스트를 가진 JPA 입장에서 어떤 트랜잭션 내에서 COMMIT 하기 전에 PK (ID) 를 사용해야 한다면 어떻게 해야할까? em.persist(entity) 시점에 INSERT 쿼리를 실행한다. (아직 COMMIT 전) Member.java @Entity @Table(name = "member") @NoArgsConstructor(access = AccessLevel.PROTECTED) @Getter public class Member { @Id @GeneratedValue(strat..