data jpa사용시 ok (200)이 나와도 db에서 변화가 없음 => 임시 해결책-> repository 두개 동시 사용해서 update,delete 쿼리로 작성

원인 : hibernate쿼리를 확인해보니 select 만 실행되고 delete, update가 실행안됨 => 이유 불명,,?

Requestbody로 List를 받으려하면,

@PostMapping("{product_id}/option/new")
    public ApiResult<String> saveOption(@PathVariable("product_id") Long productId, @RequestBody List<String> names, @RequestBody List<ProductChildOptionRequest> childOptionRequests){
        LinkedList<ProductChildOptionRequest> linkedList = new LinkedList<>();
        linkedList.addAll(childOptionRequests);
        productOptonService.saveOption(productId, names, linkedList);
        return OK("저장되었습니다.");
    }

아래의 error 메세지가 발생한다.

"message": "JSON parse error: Cannot deserialize instance of `java.util.ArrayList<java.lang.Object>` out of START_OBJECT token; nested exception is com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot deserialize instance of `java.util.ArrayList<java.lang.Object>` out of START_OBJECT token\n at [Source: (PushbackInputStream); line: 1, column: 1]",

문제에 대한 해답은 이쪽 링크 에서 찾았다.
JSON은 Collection으로 deserialize 되지 않기때문에 일어나는 문제이다.

해결 방법으로는 여러가지가 소개되었는데, json으로 넘어오는 값을 변동하기는 불편해서 paramter를 담는 일급 컬렉션을 선언해준다.
(그리고 parameter에 @RequestBody 도 두번이나 선언되어서 해당 에러도 같이 뜬다. I/O error while reading input message; nested exception is java.io.IOException: Stream closed )

변경된 코드는 다음과 같다.

@PostMapping("{product_id}/option/new")
    public ApiResult<String> saveOption(@PathVariable("product_id") Long productId, @RequestBody OptionRequest optionRequest){
        LinkedList<ProductChildOptionRequest> linkedList = new LinkedList<>();
        linkedList.addAll(optionRequest.getChildOptionRequests());
        productOptonService.saveOption(productId, optionRequest.getNames(), linkedList);
        return OK("저장되었습니다.");
    }

@Getter
@Setter
class OptionRequest {
    private List<String> names;
    private List<ProductChildOptionRequest> childOptionRequests;
}

토큰 적용 경로와 적용제외 경로를 구별해서 uri를 수정해야 할것같음.

현재 설정 :
public void addInterceptors(InterceptorRegistry registry){
registry.addInterceptor(jwtInterceptor).addPathPatterns("/api/") //기본 적용 경로
.excludePathPatterns(Arrays.asList("/api/user/")); //적용 제외 경로
}

ex)
댓글 수정,추가,삭제 경우에는 접속한 유저의 토큰을 달고다녀야 하지만, 댓글 보기는 비로그인 유저도 볼수 있어야함.
작품또한 Read를 뺀 경우에는 토큰이 필요하지만, Read는 비로그인 유저도 볼수 있어야함. 유저부분도 동일.

현재 명세서 작성한것 중, 토큰이 필요없는 uri 리스트를 보면

1. 작품 전체 리스트 가져오기 : /api/w/product?page={페이지넘버}&size={가져올작품갯수}
2. 특정 카테고리 작품 리스트 가져오기 : /api/w/category/{category_id}
3. 특정 작품 가져오기 : /api/w/product/{product_id}
4. 회원가입 : /api/user/join
5. 회원 로그인 : /api/user/login
6. 회원 이메일 찾기 : /api/user/id-finding
7. 회원 비밀번호 찾기 : /api/user/pw-finding

토큰이 필요없는 uri들 구분을 위해 /api/t/producdt/~~ 식으로 t를 추가해서
밑에와 같이 설정하는것을 생각중.

바꾼 설정 :
public void addInterceptors(InterceptorRegistry registry){
registry.addInterceptor(jwtInterceptor).addPathPatterns("/api/") //기본 적용 경로
.excludePathPatterns(Arrays.asList("/api/t/")); //적용 제외 경로
}

이밖의 의견제시 환영~

1. PromotionProduct 는 Promotion을 참조하고 있음
2. PromotionProduct 는 Product 도 참조하고있음
3. Promotion을 지울때 product_id constraint가 발생

수정하기 위해서 참조한 내용
https://modimodi.tistory.com/22

=> 생각대로 안지워짐,,

docker image 생성시 기존의 방식은

로컬에서 jar 생성 -> jar를 이용해 docker build로 이미지 생성

이번에는 jar를 참조만하는게 아니라 직접 build 과정까지 한번에 이루어지게끔 욕심내서 구성해보았으나,

FROM gradle:6.8.3-jdk11 AS builder
WORKDIR /app
COPY --chown=gradle:gradle ./ourdus-spring ./
RUN gradle build --no-daemon


FROM openjdk:11-jre-slim
EXPOSE 8080
ARG JAR_FILES=/app/build/libs/*.jar
COPY --from=builder ${JAR_FILES} Ourdus-springboot.jar
ENTRYPOINT [ "java", "-Dspring.profiles.active=dev", "-jar", "Ourdus-springboot.jar" ]

wsl에서는 잘 작동하는데, 개인용 free tier EC2에서는 build하다가 자꾸 뻗어버린다...
관련해서 찾아보니, gradle이 빌드할때마다 종속성을 다시 다 다운로드해서 그런 것이라 예상.

공식 문서들을 찾아보면 dockerfile 내에서는 build를 진행하지 않는데, 제대로 만들자면 기존의 jar만 참고하는 코드에서도 개선할 부분이 보인다.

(이전 파일)
FROM openjdk:11-jre-slim
WORKDIR /app
EXPOSE 8080
ARG JAR_FILES=/app/build/libs/*.jar
COPY --from=builder ${JAR_FILES} Ourdus-springboot.jar
ENTRYPOINT [ "java", "-Dspring.profiles.active=dev", "-jar", "Ourdus-springboot.jar" ]

자 그렇다면, 어디를 개선해야할까? Spring docs와 Baeldung를 참고해보자면

This works fine for most applications, but there are a couple of drawbacks.
First, we are using the fat jar created by Spring Boot. This can impact startup time, especially in a containerized environment. We can save startup time by adding the exploded contents of the jar file instead.
Second, Docker images are built in layers. The nature of Spring Boot fat jars causes all application code and 3rd party libraries to be put into a single layer. This means even when only a single line of code changes, the entire layer has to be rebuilt.
By exploding the jar before building, application code and 3rd party libraries each get their own layer. This allows us to take advantage of Docker's caching mechanism. Now, when one line of code is changed, only that corresponding layer needs to be rebuilt.

fat jar를 만들어 쓰면 컨테이너 시작시간도 느려지고, 코드 하나 바뀔때마다 rebuild해야하는 단점이 크다.
그래서 caching을 이용해 한 줄 변경시 해당 layer만 다시 빌드하게끔 만들어준다.

<<<< 수정필요
FROM openjdk:8-jdk-alpine
RUN addgroup -S spring && adduser -S spring -G spring
USER spring:spring
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]


FROM adoptopenjdk:11-jre-hotspot as builder
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

FROM adoptopenjdk:11-jre-hotspot
WORKDIR /app
EXPOSE 8080
COPY --from=builder dependencies/ ./
COPY --from=builder snapshot-dependencies/ ./
COPY --from=builder spring-boot-loader/ ./
COPY --from=builder application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

FROM openjdk:11-jre-slim


ARG JAR_FILES=/app/build/libs/*.jar
COPY ${JAR_FILES} Ourdus-springboot.jar
ENTRYPOINT [ "java", "-Dspring.profiles.active=dev", "-jar", "Ourdus-springboot.jar" ]

진행해야하는 목록

• main화면

  Product의 Paging 必
  관련 링크 1, 2

• 1.2.1 - 회원가입

  Jwt를 활용한 로그인 및 인증 유지 必

• 1.3 - ID/Password 찾기

  핸드폰번호로 ID(email), 핸드폰번호+ID(email)로 passwd 찾기
  Email 인증 必 (spring boot starter mail package 이용)
  *이외에 아이디어 있으시면 의견 주세요!
  그리고, ID/PW 둘다 핸드폰 번호 인증으로 찾는데 이메일 인증으로 찾게 된다면, ID는 어떻게?? (이메일 == 입력 ID)

• 2.3 - 내 정보

  GET user/{user_id}에서 해당 화면에 필요한 정보 조회해서 반환하는 mapping 必
  내 정보 네 가지 중에서는적립금만 구현 가능, 나머지는 아직 x라 하드코딩 요청

• 2.3.1 - 주문 내역

  2.3의 연장선. 주문(Order) Entity 생성 및 조회 구현 必

• 2.3.4 - 회원정보 수정 및 주소 추가/수정

  주소(배송지, Address) Entity 생성 및 CRUD 구현 必

• 2.3.5 회원탈퇴
• 💥 Data Crawling

  임시 데이터로 쓸 내용들(User, 배송지, 주문 등등 긁어올수 없는것), 작품 및 작품 연관 table들

프론트에게 요청하는 사항

1. 2.3 내 정보에서 적립금을 제외한 세 가지 항목 하드코딩 요청
2. ID/PW 찾기에서 ID는 무엇을 구분자로?
3. Jwt를 활용한 로그인을 구현할 예정, 참고 요청
4. 작품/클래스의 Option부분 간소화 요청

1. 최대한 단방향으로 처리할것 (어쩔수 없는경우에만 양방향 연관관계 사용)

2. 주인을 외래키 있는곳으로 지정할 것

3. 양방향 매핑시 무한루프 주의 (toString, lombok, JSON 생성 라이브러리)

   → toString 사용자제

   → lombok에서 toString 생성은 빼고 사용

   → 데이터를 주고받을때 엔티티를 사용하지말고 DTO를 만들어서 사용

4. 양방향 연관관계 삭제 오류 (제약조건 때문에)
   https://stackoverflow.com/questions/21569970/how-to-delete-child-or-parent-objects-from-relationship
   https://velog.io/@sonaky47/JPA-delete%EA%B0%80-%EC%95%88%EB%90%9C%EB%8B%A4
   https://hellokoding.com/deleting-data-with-jpa-hibernate/

작품(Product)과 주문(Order)을 설계하는 과정

1. 작품을 저장해보자.

한 작품마다 고유의 이름과, 고유의 작가, 배송비, 몇명 구매했는지 구매수, ... 등등이 포함되어있다. 이중에서 고려해야할 점은 한 작품은 하나의 카테고리에 속한다는 것과, 옵션과 이미지는 여러개가 존재한다는 것이다.
개개별의 작품이 속해야하는 분류인 PROUDCT_CATEGORY를 선언해주고, 그 카테고리의 PK인 category_id를 FK로 저장해둔다.

다음으로는 옵션과 이미지를 생각해보자. PRODUCT 테이블의 column에 여러 개의 옵션이나 이미지를 넣기에는 atomic value를 보장하지 못한다. (제1정규화 필요)

여러 개의 column을 만들면 되지 않을까? column마다 이미지1, 이미지2, 이미지3 ...
이런 방법은 이미지의 최대 개수가 고정되어있다면 가능할 수는 있겠지만 이미지가 채워지기까지 null 값이어야 한다는 점이 매우 큰 단점으로 작용한다. 덧붙여 col도 너무 길어진다.

고로 PRODUCT_OPTION과 PRODUCT_IMAGE 라는 테이블을 각각 생성해준다.

옵션은 어떻게 처리해주어야할까?
사실 Idus의 옵션은 아래의 그림처럼 두 분류의 옵션으로 구성되어있다.

전체 옵션과 각 전체 옵션별 세부 옵션이 존재한다.
이런 구조를 띄려면 전체 옵션에는 parent_option, 세부 옵션에는 child_option으로 생성해주어 각 parent별 child 옵션을 하나씩 선택해주어 주문을 하게끔 구성되어있다.
옵션이 존재하지 않는 작품에는 옵션 선택 없이 작품의 정보만 구성된다.

2. 주문을 해보자.

작품의 각 세부옵션을 클릭해주면

전체옵션:세부옵션/전체옵션:세부옵션/전체옵션:세부옵션
수량(1)                     가격 product 가격+옵션 가격들

의 형태의 주문양식이 지정된다.
각 주문양식은 장바구니 혹은 주문하기 버튼을 클릭시 작가의 id와 이름, 작품의 id와 이름도 함께 넘겨진다.

주문하기와 장바구니 클릭시 로그인이 되어있지 않으면 (Jwt 확인) 로그인 페이지로 redirect 된다.

2-1 '구매하기' 를 통한 바로 주문

구매하기를 누를 경우 cart_temp_id라는 uuid를 생성하여 해당 주문양식들에 저장되어있던 정보를 전달해준다.

작가의 id 및 이름, 작품의 id 및 이름, 그리고 두 가지의 주문양식의 정보를 함께 전달한다.
'바로주문' 형태에서는 X 버튼으로 항목의 삭제가 불가능하다.

로그인이 되어있지 않는다면 redirect 시키고, 그 때 cart_temp_ip는 query paramter에 담겨서 전달된다.

2-2. '장바구니'를 통한 장바구니 담기 후 주문

장바구니에 담게된다면 주문양식의 정보들을 cart_detail에 담게된다.
cart_detail에는

다음과 같은 정보들이 필요할 것이다.

담은 장바구니의 정보들은

장바구니 버튼을 클릭시 장바구니 detail의 전체 list를 보여준다.

바로주문과는 달리 X 버튼 혹은 톱니바퀴 버튼을 통해 삭제 or 옵션수정이 가능하다.

• 옵션 수정 기능의 구현?

이후에 결제하는 방식은 두 가지 방식이 동일하다.

3. 결제해서 주문하기

결제하기에서는 주문하려는 사람의 정보 (이름, 전화번호)와 주소지 세가지를 선택할 수 있게 설정해두었고
주문 작품 정보에서는 주문양식 형태로 불러온 정보들을 전달받아 해당 정보들을 표시해준다.

결제를 진행하면
아래와 같이 주문정보 (ORDER) 라는 테이블에 주문한 날짜와 총 가격 및 결제정보를 저장해주고
개개별의 주문양식들을 주문상세 (ORDER_DETAIL) 테이블에 저장해준다.

이때 주문 상세번호는 각 주문번호당 해당하는 주문양식들의 순서를 1, 2, 3 순으로 지정하여 넣어준다.

• 화경 : 프로모션 구현
• 서연 : 댓글 구현 및 댓글 내용 crawling -> 크롤링을 2/20
• 혜진 : 리뷰 구현

각자 구현한 파트는 각자 api 명세서에 기술

#스프링의 큰 특징 : IoC를 구체적으로 DI라는 방식을 통해 의존성 역전 제어를 함

1. IoC (Inversion of Control)

• 제어가 역전됨 : 개발자가 직접 객체를 관리하지 않고 스프링 컨테이너에서 직접 객체를 생성하여 해당 객체에 주입 시켜준 것. (B라는 객체가 스프링 컨테이너에서 관리되고 있는 Bean 이라면 @Autowired를 통해 객체를 주입받는상황).
• 객체 생명 관리, 흐름 제어를 제 3자에게 위임하는 프로그래밍 모델

2. DI(Dependency Injection)

• 오브젝트 레퍼런스를 외부(스프링컨테이너)에서 주입받고, 이를 통해 여타 오브젝트와 다이내믹하게 의존관계가 만들어지는 것이 핵심
• IoC 프로그래밍 모델을 구현하는 방식중 하나
• 클래스타입이 고정되어있찌 않고, 인터페이스 타입의 파라미터를 통해 다이나믹하게 구현 클래스를 결정해서 제공 받을수 있어야함.

#Spring initializer

• 요즘에는 Maven보다 Gradle -> build툴로 dependencies 관리
• gradle : 버전설정하고 라이브러리 땡겨오는거
• snapshot 아직 만들고있는 버전
• dependencies : 어떤 library 땡겨올지
• Thymeleaf : html을 만들어주는 템플릿 엔진

#라이브러리 살펴보기

• 필요한 의존성들을 다 땡겨옴.
• ex) thymeleaf가 필요한 라이브러리 땡겨옴. 그 라이브러리들이 필요한거 또 땡겨옴
• 자바 메인메소드만 실행해도 웹서버가 뜸. tomcat서버 깔필요없음. 내장되어있기 때문 : embeded

#스프링부트 주요 특징

1. 스프링부트 라이브러리
   spring-boot starter-web
   spring-boot-starter-tomcat : 톰캣(웹서버)
   spirng-webmvc : 스프링 웹 MVC
   spring-boot-starter-thymeleaf: 타임리프 템플릿엔진(View)
   spring-boot-starter(공통) : 스프링 부트 + 스프링 코어 + 로깅
   spring-boot
   spring-core
   spring-boot-starter-logging
   logback,slf4j

2. 테스트 라이브러리
   spring-boot-starter-test
   junit : 테스트 프레임워크
   mockito: 목 라이브러리
   assertj : 테스트 코드 좀더 편하게 작성
   spring-test : 스프링 통합 테스트 지원

#Controller 만들기

• 어노테이션 필요. @controller
  -@GetMapping("hello") 는 웹어플리케이션에서 /hello라고 들어오면 해당 메소드를 호출한다는 뜻.
• return hello면 resources의 templates의 폴더 밑에 hello.html을 찾아서 렌더링을 함
• 컨트롤러에서 리턴값으로 문자를 반환하면 viewResolver가 화면을 찾아서 처리함.
  • 스프링 부트 템플릿엔진 기본 viewName 매핑
  • resources:Templates/ + {ViewName} + .html

#스프링 웹 개발기초

• 정적 컨텐츠 : 파일을 그대로 전달해주는것
• MVC와 템플릿 엔진(php,jsp): 서버에서 뭔가 변경을 해서 HTML에 내려주는것
• API : 데이타 내려줄때

#정적컨텐츠
-resources -> static -> [~~~].html 올리면 서버 실행후 localhost:8080/[~~~].html하면 결과물 바로 출력

• 클라이언트가 localhost:8080/[~~~].html 치면 내장 톰캣서버가 받아와서 먼저 컨트롤러에서 찾아봄. 그러나, 관련된 매핑이 된 컨트롤러가 없으면 내부 resources: static에 있는걸 찾음. 이때, 있으면 반환.

#MVC와 템플릿 엔진
MVC: Model, View, Controller

• 요즘은 뷰와 컨트롤로 나누는게 트렌드
• 뷰는 화면과 관련된 일만, 컨트롤러는 비즈니스 로직이나 서버 뒷단에 관련된 일들

-thymleaf의 장점 : html을 써보고 바로 열어도 껍데기를 볼수있음
-

hello! empty

• 과정 : 웹브라우저에서 localhost:8080/hello-mvc 넘기면 스프링부트 띄울때 내장 톰켓서버에 던져짐. 그러면, 스프링 컨테이너 컨트롤러에서 있네 확인하고 return값과 model를 viewResolver에 던져줌. viewResolver가 템플릿에 똑같은 html찾아서 렌더링 해서 변환한 html을 웹 브라우저에 띄움.

#API

• 객체반환
• @responsebody 는 그대로 data를 올림.
• 객체를 리턴하면 json형태로 반환
• 과정 : 웹 브라우저에서 localhost:8080/hello-api 치면 톰캣 내장서버에서 받아서 스프링컨테이너에 던짐. 컨트롤러에 찾았는데 @responsebody가 붙어있으면, http응답에 바로 던짐. 이때 string이면 stringConverter , 객체면 jsonConverter 이용해서 웹서버에 넘김. (기존에는 viewResolver)
• 객체 -> json 바꿔주는 대표적인 라이브러리는 Jackson과 구글의 지슨?. 스프링에선 Jackson사용

#회원 도메인 리포지토리 만들기

• 널이 반환될수 있는 경우엔 optional을 붙임.

#회원 리포지토리 테스트 케이스 작성

• 자바에서는 JUnit이라는 프레임워크 사용해서 테스트함
• Assertions => junit 쓰는 방법 / assertj 쓰는방법 두가지
• alt+enter 로 assertions 위로 올리고 assertThat으로 바로사용
• 비슷한 객체 생성시 복사하고 이름 변경할때 쓰는 키 : shift + f6
• test 메소드들은 순서 정해져있지않고 각각 실행되므로, test 끝나고나면 data를 클리어 해주어야함
• @AfterEach 메소드 끝날때마다 실행할것

#회원 서비스 개발

• service 패키지는 비즈니스에 의존적으로 설계, repository는 기계적으로 개발스럽게 naming
• alt + ctrl + v : 단축키는 받아오는 변수 자동생성
• ifPresent : null이 아닐때 (Optional이라 가능)
• orElseGet : 값있으면 꺼냄
• 자주쓰는 메소드 뽑아내기 : alt+ctrl+shift+T -> extract method

#회원 서비스 테스트

• 클래스 이름 갖다대고 ctrl+Shift+T 로 간편하게 test만들기
• test 메소드는 과감하게 한글로 바꿔도 괜찮
• given / when / then 패턴으로 짜보기
• 오른쪽 로직이 실행될때 왼쪽 예외가 터져야함
  assertThrows(IllegalStateException.class, ()->memberService.join(member2));
• @beforeeach 동작하기전에 넣는것

#컨트롤러
#dependency 인젝션 (의존관계 주입해주는거)

• @controller붙이면 스프링 뜰때 해당 컨트롤러를 생성을해서 스프링 컨테이너가 관리를 함.
• 생성자에 @Autowired붙으면 스프링컨테이너에 있는거랑 연결시켜줌.
• 클래스 위에 @service 붙으면 스프링이 올라올때 해당 클래스를 스프링컨테이너에 등록해줌.
• 컨트롤러에서 외부요청 받고 서비스에서 비즈니스 로직만들고 리포지토리에서 데이타를 저장하는게 정형화된 패턴

#스프링 빈 등록하는 2가지 방법

• 스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본으로 싱글톤(유일하게 하나만)으로 등록한다. 같은 스프링 빈이면 모두 같은 인스턴스임.

1. 컴포넌트 스캔과 자동 의존관계 설정

• 위에서 한거. 어노테이션 사용
• @component 에노테이션 있으면 스프링 빈으로 자동 등록
  -@controller, @service, @repository안에 다 @component 포함하고있음

2. 자바코드로 직접 스프링 빈 등록하기

#개방-폐쇄 원칙(OCP , Open-Closed Principle)
: 확장에는 열려있고, 수정, 변경에는 닫혀있다
: 기능을 완전히 변경해도 애플리케이션 전체 수정할필요가 없음
: 스프링의 DI(Dependencies injection) 사용하면 기존코드를 전혀 손대지 않고, 설정만으로 구현클래스를 변경 가능

#통합 테스트
@SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행한다
@transactional : 테스트 케이스에 이 애노테이션이 있으면, 테스트 시작 전에 트랜잭션을 시작하고, 테스트 완료 후에 항상 롤백한다. 이렇게 하면 DB에 데이터가 남지 않으므로 다음 테스트에 영향을 주지 않는다.

#DB접근방식
1.순수 Jdbc

• 스프링을 통해 datasource를 주입 받음
  -Sql문 직접 다씀
• connection 객체를 직접 관리. 수동으로 열고 닫음
• preparedstatement, resultset객체를 통해 어떤 조건을 전달하고 결과값을 전달받음.

2.스프링 JdbcTemplate

• JDBC API에서 본 반복코드를 제거해주는 라이브러리. sql은 직접 작성해야함.
• 순수 Jdbc와 동일한 환경설정 하면됨

3.JPA

• 기존의 반복코드는 물론이고, 기본적인 sql도 jpa가 직접 만들어서 실행해줌.
• 인터페이스 제공.
• 구현은 여러업체들이 함.
• db가 알아서 생성해주는 것을 GENERATE TYPE.IDENTITY라고 함
• 어노테이션 추가해서 데이터베이스랑 매핑함
• EntityManager를 주입받아야함
• jpql : 테이블 대상으로 쿼리 날리는게 아니라, 객체 대상으로 쿼리날림.그럼 sql로 번역이 됨. pk기반이 아닌것들.
• 모든 데이터변경이 @transactional 안에서 실행되야함
• 기본적인 crud 직접 쿼리짤필요없고, select할때는 jpql는 짜야함.
• sql 구조를 java application 내에 적용하지 않아도됨. 조인쿼리를 jpa에서 자동으로 만들어줌

4.스프링데이터 JPA

• JPA를 편리하게 사용하도록 도와주는 기술
• 스프링 부트와 JPA만 사용해도 개발 생산성이 많이 증가
• 구현클래스 작성 없이 인터페이스로만 개발이 끝남

#개념정리

• Service : 실제로 비즈니스 로직 시행. repository를 이용하여 실제로 저장해줘야함.
• Dto 사용해 컨트롤러와 서비스 사이에서 데이터를 주고받음.
• Entity : db테이블과 매핑되는 객체
• repository: 데이터 조작을 담당. 인터페이스로 생성하며 JpaRepository를 extends함. 값은 매핑할 entity와 id의 타입.
• 스프링빈: 스프링 컨테이너에 의해 만들어지는 자바 객체
• @Autowired : 자동으로 스프링 빈 객체를 특정 참조변수에 매핑해주는 것
• 스프링 빈 어노테이션 종류 : @component(상위), @service, @controller, @repository, @bean, @configuration
  이를 통해 필요한 빈들을 등록하고 필요한 곳에서 @Autowired를 통해 주입받아 사용하는것이 일반적.

• API document 작성 및 프론트 분들과의 협의

• RDS와의 연동 및 크롤링 데이터 import

- [ ] EC2에 React+Node + Nginx + SpringBoot 배포

• 온라인 클래스 주문 (혜진)

• 내용을

• 적어줍시다

• 나아중에 구현할 파트
  • 시큐리티 (혜진)

• 환경 셋팅은
  Spring Boot 2.3.8 (JPA)
  Java 11

• AWS RDS - MySql

이건 조금 고려사항인게, 바로 연동으로 들어가도 괜찮을지? 1. 바로 RDS 2. H2 쓰다가 토요일 밤에 RDS로 연동

하단의 고려사항들은 내용이 길어서 간단히 요약해보자면,

1. Controller에서 받는 paramter랑 return type 통일 권장
2. Setter를 지양합시다 -> builder 사용 권장

1. Handler Method argument 및 Return value 통일

*참고 페이지: https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-methods ,  https://www.xspdf.com/resolution/58586250.html*

• Spring Web MVC에서는 @RequestMapping annotation을 활용해 request를 controller method에 mapping할 수 있다.

Handler Method argument

• mapping받는 handler method인 대표적인 예로 @PathVariable, @RequestParam, @requestbody, @ModelAttribute 등이 존재

• @PathVariable : URI 템플릿 변수에 접근하기 위해 사용 ex) product/{product_id}

• @RequestBody
  : HTTP request body에 접근하기 위해 사용. (주로 JSON)

  Body content is converted to the declared method argument type by using HttpMessageConverter implementations. See @RequestBody

• @ModelAttribute
  : 데이터 바인딩과 validation이 적용된 model에 존재하는 속성에 접근하기 위해 사용 (존재하지 않으면 인스턴스화됨) model은 HTTP Servlet request parameter의 이름과 매치되는 필드 이름으로 덧씌워진다. 참고로 @RequestParam은 servlet reuqest paramter를 1:1 매칭, object는 model 사용

  • 이후에 model.setAttribute()로 추가한 속성들은 HttpRequest Servlet에 추가됨

  For access to an existing attribute in the model (instantiated if not present) with data binding and validation applied. See @ModelAttribute as well as Model and DataBinder.

• ❗결론적으로 정리해보자면, http query paramter를 이용하는 pathvariable, modelattribute, requestparam과는 달리 requestbody는 http request body를 이용한다.

  비교글1과 비교글2 을 꼭 읽어볼것!!

Return value
-@ResponseBody (@RestController 사용시 자동 적용)

1-1. Controller의 Return type?

• ResponseEntity<B>
  : The return value that specifies the full response (including HTTP headers and body) is to be converted through HttpMessageConverter implementations and written to the response. See ResponseEntity.

  관련 메소드 정리는 이곳 참고!

• 예시 코드

    @PostMapping("join")
   public ResponseEntity<UserDto> join(@RequestBody JoinRequest joinRequest){
   	UserVo userVo = userService.join(
   	joinRequest.getUserEmail(), joinRequest.getUserPw(), joinRequest.getUserName(), joinRequest.getUserTel());
   	return new ResponseEntity<UserDto>(new UserDto(userVo), HttpStatus.OK);
   }
  

1-2. Exception Handling

참고 : https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-exceptionhandler , https://www.baeldung.com/exception-handling-for-rest-with-spring (solution3)

• @ControllerAdvice를 사용하여 @ExceptionHandler methods와 함께 이용

• Spring Guide 예시코드

    @ControllerAdvice
    public  class RestResponseEntityExceptionHandler 
      extends ResponseEntityExceptionHandler { 
    @ExceptionHandler(value = { IllegalArgumentException.class, IllegalStateException.class })  
      protected ResponseEntity<Object> handleConflict( RuntimeException ex, WebRequest request) { 
        String bodyOfResponse = "This should be application specific"; 
        return handleExceptionInternal(ex, bodyOfResponse, new HttpHeaders(), HttpStatus.CONFLICT, request); 
        } 
   }
  

• 위의 사례들을 종합해본 예시 코드 (스터디 참고)
  : ResponseEntity<> type을 활용한 ApiResult와 ApiError, @ControllerAdvice를 활용한 AllExcpeitonHandler

  public class ApiResult<T> {
  	private final boolean success;
  	private final T response;
  	private final ApiError apiError;
  	private ApiResult(boolean success, T response, ApiError apiError) {
  	this.success = success;
  	this.response = response;
  	this.apiError = apiError;
  	}
  
  	public static <T> ApiResult<T> OK(T response){ //parameter와 return이 동일해서 <T> ApiResult<T>
  		return new ApiResult<>(true, response, null);
  	}
  
  	public static ApiResult<?> ERROR(String errorMessage, HttpStatus status){ //Gerneric<?> 사용
  		return new ApiResult<>(false, null, new ApiError(errorMessage, status));
  	}
  
  	public boolean isSuccess() {
  		return success;
  	}
  
  	public T getResponse() {
  		return response;
  	}
  
  	public ApiError getApiError() {
  		return apiError;
  	}
  
  	@Override
  	public String toString() {
  		return "ApiResult{" +
  		"success=" + success +
  		", response=" + response +
  		", apiError=" + apiError +
  		'}';
  	}
  }
  

  public class ApiError {
     private final String message;
     private final int status;
     ApiError(String message, HttpStatus status) {
         this.message = message;
         this.status = status.value();
     }
     public String getMessage() {
     		return message;
     }
     public int getStatus() {
     		return status;
     }
     @Override
     public String toString() {
     		return "ApiError{" +
     		"message='" + message + '\'' +
     		", status=" + status +
     		'}';
     }
  }
  

  @ControllerAdvice
  public class AllExceptionHandler {
  
  private ResponseEntity<ApiResult<?>> newResponse(Throwable throwable, HttpStatus status){
     HttpHeaders headers = new HttpHeaders();
     headers.add("Content-Type", "application/json");
     return new ResponseEntity<>(ERROR(throwable.getMessage(), status), headers, status);
  }
  
  @ExceptionHandler(Exception.class)
  public ResponseEntity<?> exceptionAll(Exception e){
     return newResponse(e, HttpStatus.BAD_REQUEST);
     }
  }
  

2. Setter의 사용을 최소화, 그리고 Builder Pattern 제안

• Setter를 지양해야하는 이유?

  아주 잘 정리된 질문과 빛영한님의 답변이 담긴 이 글을 꼭 읽어주세요!

• 왜 Builder를 써야하는가?

  Effective Java item2와 관련된 글 (아주좋은예시 예시1 예시2 예시3 공식문서)을 참고하시면 좋습니다!
  예시3은 Entity에서 lombok을 활용한 @builder를 잘 설명하고 있으니 꼭 읽어보세요~!

• 적용한다면 어떻게 해야하는 거지?
  해당 주소의 Product Entity를 보자면, 현재 Setter도 사용하고 그저 그런 생성자로 Product를 만든다.

   @Entity
   @Getter @Setter //TODO Setter 수정
   public class Product {
   	@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
   	@Column(name = "product_id")
   	private Long productId;
   	@ManyToOne
   	@JoinColumn(name="author_id")
   	private User user;
   	@ManyToOne
   	@JoinColumn(name= "category_id")
   	private ProductCategory productCategory;
   	@Column(name = "product_name")
   	private String productName;
   	@Column(name= "product_price")
   	@ColumnDefault("0")
   	private int productPrice;
   	@Column(name= "product_rate")
   	@ColumnDefault("0")
   	private int productRate;
   	@Column(name= "product_review_num")
   	@ColumnDefault("0")
   	private int productReviewNum;
   	@Column(name = "product_hit")
   	@ColumnDefault("0")
   	private int productHit;
   	@Column(name = "product_purchase")
   	@ColumnDefault("0")
   	private int productPurchase;
   	@Column(name = "product_option_num")
   	@ColumnDefault("0")
   	private int productOptionNum;
   	
   	public Product(User user, ProductCategory productCategory) {
   		this.user = user;
   		this.productCategory = productCategory;
   	}
   		public Product() {
   	}
   }
  

  -> 이 친구를 Builder Pattern으로 만들려면?

  1. Effective Java style

     • 누가 필수 인자인거지?

       product를 구성하는데 반드시 필요한 요소들을 떠올려보자. product가 생성될때 form에서 넘어와야만하는 값들이 뭐였더라? authorid와 categoryid, 그리고 이름(productName)과 가격(productPrice)도 필요하다.

       • 그 외엔 선택인자라고 생각하면 된다.

        (위는 생략)
            public static class Builder {
        		private final User user; //User값만 변동되지 않는다. (update 불가)
        		private ProductCategory productCategory;
        		private String productName;
        		private int productPrice;
        		private int productRate;
        		private int productReviewNum;
        		private int productHit;
        		private int productPurchase;
        		private int productOptionNum;
                public Builder(User user, ProductCategory productCategory, String productName, int productPrice, int productOptionNum ) {
                    this.user= user;
                    this.productCategory = productCategory;
                    this.productName = productName;
                    this.productPrice = productPrice;
                    this.productOptionNum  = productOptionNum;
                }
                public Builder productCategory(ProductCategory  productCategory) {
                    this.productCategory= productCategory;
                    return this;
                }
                public Builder productName(String productName) {
                    this.productName= productName;
                    return this;
                }
                ...
                public Product  build(){
                return new Product(this);
             }
              
            public Product build(Builder builder) {
                this.user= user;
                this.productCategory = productCategory;
                this.productName = productName;
                this.productPrice = productPrice;
                ....
                this.productOptionNum = productOptionNum;
            }
            }
             ```
       

          이후의 생성은 다음과 같이 진행한다.
          Product test = new Product
         				        .Builder(user, productCategory, "이름", 30000, 3)
         				        .productHit(3) 	//이건 넣어도 되고 안넣어도 무방, setter역할
         				        .build();
       

     2. Lombok 활용

        @Builder(builderClassName="defaultBuilder", builderMethodName="defaultBuilder")
        public Product(User user, ProductCategory productCategory, String productName, int productPrice, int productOptionNum){
           	this.user= user;
            this.productCategory = productCategory;
            this.productName = productName;
            this.productPrice = productPrice;
            this.productOptionNum  = productOptionNum;
           }
         @Builder(builderClassName="ByUserBuilder", builderMethodName="ByUserBuilder")
        public Product(User user, String productName, int productPrice, int productOptionNum){
           	this.user= user;
            this.productName = productName;
            this.productPrice = productPrice;
            this.productOptionNum  = productOptionNum;
           }  
        

        이후 생성시
        Product test = new Product
        		      .defaultBuilder()
        		      .user(user)
        		      .productCategory(productCategory)
        		      .productName(productName)
        		      .productOptionNum(productOptionNum)
        		      .build();
        						
        혹은 category가 없을때
        Product test2 = new Product
        			.ByUserBuilder()
        			.user(user)
        			.productName(productName)
        			.productOptionNum(productOptionNum)
        			.build();
        

<진행과정 >

1. aws inbound 규칙-> 항상 위치무관 IP설정을 해두자!! (인바운드가 설정 되어있지 않으면 비번까지 다 설정해도 timeout 발생
2. csv 파일 mysql workbench read 문제 : 정확한 이유는 모르겠으나 UTF8로 설정해도 한글을 읽지 못하는 걸로 판단
3. 2의 대안으로 json파일로 변형해서 저장-> json 파일로 변형하면 들어감 -> 단, varchar, int 등등 타입을 제대로 맞춰주지 않으면 import성공 후에 0개가 생성되었다고 뜸
4. json 파일로 변형할때 python으로 간단하게 전처리 가능