발자국남기기

현재 Spring Security를 사용하여 로그인, 로그아웃을 구현한 상태이고 인증(로그인)하지 않은 사용자는 게시판에 접속할 수 없도록 구현해놓았다. Controller 파라미터로 page(페이징 변수), category(카테고리별 조회), myPost(내 게시물 보기), searchDto(검색창)를 받는다. 1. page page는 defaultValue를 0으로 설정하였기 때문에 값을 설정하지 않으면 0페이지부터 보여준다. 만약 다음 페이지 버튼을 누르게 되면 현재 페이지에서+1을 한 값이 page 변수에 담기고, 이전 페이지 버튼을 누르면 현재 페이지에서 -1을 한 값이 담긴다. 2. category required 속성을 false로 지정해놓았기 때문에 category 값을 주지 않으면 nul..

1. 지연 로딩과 조회 성능 최적화 엔티티를 직접 노출 저장된 모든 order를 찾아 리스트에 담고 엔티티를 그대로 반환 Postman으로 요청을 전송해보자. 먼저 앞서 공부한 것과 같이 엔티티를 그대로 노출하는 것은 굉장히 좋지 않은 행위이다. 또한, 응답을 보면 무한 loop에 빠져 StackOverflow가 발생하는 것을 확인할 수 있다. 이는 Order와 Member가 현재 양방향 관계로 매핑되어 있기 때문에 양방향관계에 의한 순환 참조로 인해 무한 Loop가 발생하기 때문이다. 이를 어떻게 해결하여야 할까? 현재 주문을 조회하고 있기 때문에 반대쪽 Member, OrderItem, Delivery에서 Order로 오는 것을 @JsonIgnore을 통해 막아야한다. 즉, 양방향 연관관계가 걸리는 ..

엔티티를 파라미터로 받을 경우의 문제 컨트롤러 엔티티 검증을 위한 @NotEmpty같은 로직들이 엔티티에 추가된다. 엔티티를 위한 매우 다양한 API가 만들어지는데, 한 엔티티에 각각의 API를 위한 요구사항들을 담기는 어려움 가장 큰 문제는 엔티티가 변경되면 API 스펙 자체가 변한다. 만약 엔티티의 name필드가 username으로 변경된다면 API 스펙 자체가 변하기 때문에 큰 문제가 발생한다. API 요청 스펙에 맞춰 별도의 DTO클래스를 만들어 DTO 객체를 파라미터로 받아야한다. 절대 파라미터로 엔티티를 바로 받지 말자!! 엔티티를 API 스펙에 노출 X 이와 같이 따로 DTO 클래스를 만들어 파라미터로 받아야한다. 예제를 위해 setter를 사용했지만 실제는 사용 X 엔티티와 표현 계층을 위..

엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있으면 변경 포인트가 많아지고, 어디서 변경되었는지를 알아내기가 어려워진다. ==> 유지보수가 어렵다. ★모든 연관관계는 지연로딩으로 설정(FetchType.LAZY) ==> 중요!!!!!! 더보기 EAGER는 하나의 객체를 DB로부터 읽어올 때 참조 객체들의 데이터까지 전부 읽어오는 방식을 뜻한다. 반대로 LAZY 타입은 게을러서, 참조 객체들의 데이터들은 무시하고 해당 엔티티의 데이터만을 가져온다. EAGER은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. JPQL을 실행할 때 N + 1 문제가 자주 발생 모든 연관관계는 LAZY(지연로딩)으로 설정해야함. 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join..

회원 - 주문 = 1 : N 회원은 여러 상품을 주문할 수 있다. 주문 - 상품 = N : M 주문은 여러 상품을 선택할 수 있고, 상품은 여러 주문에 들어갈 수 있으므로 다대다 관계 하지만 RDB는 물론 엔티티에서도 다대다 관계는 거의 사용하지 않는다. 주문 상품이라는 중간 테이블을 만들어 1대다 + 다대1 관계를 통해 다대다 관계를 구현 상품 상품은 도서, 음반, 영화로 구분 상품이라는 공통 속성을 사용하므로 상속 구조 엔티티 회원(Member) 이름, 임베디드 타입인 주소(Address), 주문 리스트(orders) 더보기 2021.05.17 - [Java/JPA] - @Embedded, @Temporal @Embedded, @Temporal @Embedded (임베디드 타입) 임베디드 타입이란 새..

https://start.spring.io/ 스프링 프로젝트를 처음 생성하면 기본적으로, application.properties라는 SpringBoot의 설정 파일을 제공한다. 이 설정 파일은 다양한 형식을 제공하는데 그 중에서 가독성이 높고 권장하는 형식인 yml로 살정해보려한다. 기본으로 생성된 application.properties를 지우고 그 위치에 application.yml 파일을 생성하면 된다. 위와 같은 형태로 환경 설정을 하게 되는데, 이는 들여쓰기 형식으로 작성되기 때문에 가독성이 높다. 또한, 반복되는 suffix에 대한 작성을 막아준다. 위의 yml형식의 파일을 properties로 작성하게되면 spring.datasource.url=jdbc:h2:tcp://localhost/~..

start.spring.io/ 먼저 프로젝트부터 생성하자. 서블릿을 사용할 것이지만 스프링을 사용하는 이유는 스프링 부트내부에 톰캣 서버도 내장하고있고 설정이 편리한 부분도 있기 때문에 스프링 프로젝트를 만들고 그 안에서 서블릿을 사용 Packaging은 War로 설정해야 JSP를 사용할 수 있음. 라이브러리 설정과 환경 설정부분은 생략하겠음. www.postman.com/downloads/ Download Postman | Try Postman for Free Try Postman for free! Join 13 million developers who rely on Postman, the collaboration platform for API development. Create better APIs—..

편리한 자동 기능을 기본으로 사용하자! 그러면 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고, 어떤 경우에 설정 정보(AppConfig)를 통해서 수동으로 빈을 등록하고 의존관계를 수동으로 주입해야 할까? 결론부터 얘기하면, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세이다. 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 추가로 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했다. 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누..

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다. 예를 들어, 할인 서비스를 제공하는데 클라이언트가 할인의 종류를 선택할 수 있다면? 스프링을 사용하여 해결해보자. 위와 같이 테스트 코드를 작성하였다. 전에 만들어놓았던 AutoAppConfig를 통하여 컴포넌트 스캔을 진행하여 스프링 빈으로 등록한다.(@Component가 붙은 클래스 모두 등록) 그리고 우리가 static으로 만든 DiscountService또한 스프링 빈으로 등록시키는데 의존관계 주입시 List와 Map형태로 RateDiscountPolicy와 FixDiscountPolicy를 주입할 것이다. 테스트를 실행시켜보면 다음과 같이 Map와 List에 조회된 모든 빈들이 들어가있고, discountService 또한 정상적으로 ..

@Qualifier("mainDiscountPolicy") 이렇게 코드를 작성하면 컴파일시 타입 체크가 안된다. 컴파일 중에 오류를 잡을 수가 없다는 의미이다.("mainnDiscountPolicy"라고 오타를 내도 컴파일은 되고 그 이후에 Exception이 발생한다.) 이를 애노테이션을 만들어서 해결해보자. 위와 같이 "mainDiscountPolicy"를 Qualifier로 가지는 애노테이션을 생성하였다. 이제 우리는 @MainDiscountPolicy를 가져다가 사용하면 되는 것이다. 위와같이 오타를 발생하면 컴파일 전에 오류를 잡아낼 수 있어진다. 이제 OrderServiceImpl의 생성자 주입에 우리가 만든 애노테이션을 넣어주면 스프링이 어떤 타입의 할인정책을 사용해야하는지 알게되는 것이다...