Spring Boot JDBC/실습

여러 테이블 서버 개발 실습

qoeka 2024. 12. 23. 20:50

2024.12.23 - [Spring Boot/이론정리] - Controller, DTO, DAO의 역할 이론 정리

 

Controller, DTO, DAO의 역할 이론 정리

Controller에서 Request DTO로의 변환이 중요한 이유 1. 데이터 검증Controller는 사용자가 보낸 요청 데이터를 Request DTO로 변환하면서 입력된 데이터의 형식이나 필수 값을 검증할 수 있다.예를 들어, "cit

tbghdus.tistory.com

 

 

이론 정리를 한번 하고 와서 보는게 이해가 쉬울 것이다. 그리고 이 글의 마지막 그림이 돌아가는 순서이기에 그 순서를 알고 실습을 해야 머리속에 잘들어온다. 처음에 이론 정리를 하지 않은 상태에서는 멘붕이 오니 조심하자.

 

 

 

일단은 디비버를 통해 데이터 베이스에 3개의 테이블을 만들어 준 뒤에 포링키를 이용해서 연결을 먼저 해준다.

 

 

 

API 명세를 보며 실습을 할건데

 

일단 회원가입 API를 만들것이다.

 

이때 주어진 내용들을 잘봐야한다. 클라이언트가 준 정보인 RequsetBody에 담긴 정보를 확인후

 

controller에가서 작업을 시작하면된다.

 

 

 

컨트롤러에서 createdUser 즉 새로생성한 유저라는 함수가 나는 필요하다. 하지만 만들어진게 없으니 서비스패키지에 UserSerivce를 만들어줘서 그안에서 생성을 해줘야한다.

 

 

 

이때 우리는 API 명세서를 다시 떠 올려야한다. 

 

API명세서에서 조건을 준게 있을 것이다. 이 조건을 Serivce에 쓰는 것이다.

 

왜냐하면 서비스라는건 함수를 만드는 곳인데 이곳에서는 포괄적인 함수를 만들기 때문이다.

 

좀 더 자세한 함수는 DAO에서 만드는데 DAO는 SQL문을 이용한 함수를 만든다.

 

위에도 마찬가지로 지금 새로 생성을 위한 함수가 필요한데 이는 DAO에서 처리할 수 있는 일이기에 우리는 DAO를 생성 해줄 것이다.

 

 

DAO에서 createdUser 를 만들고 나서 다시 서비스가서 다시 서비스를 만들어준다.

 

이때 Service에서는 다시 조건을 써준다 이메일 번호가 유효한지는 다음에 인증관련된 거랑 같이 해서 이번에는 @가 들어갔는지 아닌지 정도만 확인하는걸로 해서 이메일이 유효한지 와, 비밀번호는 최소 8자리 이상,닉네임은 2이상 30이하로 해서 작성하고 싶다는 조건을 여기다가 써주면 되는 것이다. 조건을 다썻으면 이제 다시 컨트롤러로 돌아간다.

 

 

 

 

Status Code에 조건을 이제 마무리 해 줄 차례이다.  service에서 정해둔 결과을 가지고 Controller에서 StautsCode를 작성해하면 마무리된다. 

 

 

 

 

마무리 확인  그럼 회원가입은 끝난것이다. 이런식으로 확인을 해주면서 확인해줘야한다 인텔리제이가 잘 작동한다하더라도 이곳에서 에러가 날 수 도 있기에 그렇게 되면 디버깅을 통해서 해주면된다. 

 

이때 디버깅할때

System.out.println();

 

를 활용해서 하면 좋다. 내가 틀리지 않으면 입력값이 나올 것이기에 그렇게 하나하나 쳐서 확인하다보면 화면에 뜨지 않는 부분이 나올 것이고 그곳이 내가 틀린곳이다 이런식으로 디버깅을 해나가면된다

 

 

 

로그인 서비스 역시 위 회원가입과 같은 순서로 차근 차근하면된다. 

아래 Response 에 나온건 나중에 할것이다 일단은 status : "성공" 이라고 뜬다고 받았다 가정하에 하겠다.

 

 

먼저 컨트롤러에가서 명세서에서 말한 정보들을 쓴다. RequstDTO 는  받은 내용을 바탕으로 없으면 만들어주면된다

 그리고 이제 로그인을 할 함수를 만들어주면되는데 이 역시 만들기 위해서 서비스로 가서 만들면된다.

 

 

먼저 로그인이 되지 않았을 경우를 쓴다 만약 이메일이 나 패스워드가 없거나 비었을때의 조건을 리턴 값을 정해준뒤에 try catch를 통해서 위 내용의 예외 처리를 해준다. 

  

이렇게 service 를 완성 시켜준 다음 다시 controller 로 가서 남은 코드를 완성 시켜주겠다.

 

 

 

API 명세서를 보면 StatusCode가 있는데 그걸 보고 남은 조건을 여기서 충족 시켜 완성해주면된다.

 

 

 

 

로그인과  같은 순서로 작성하면된다.

 

 

 

 

여기서 DAO에서 위와 다른게 있다면 return을 할떄  queryForObject는 한줄만 나오게 하는 것이고 RowMapper는 SQL 조회 결과를 객체로 매핑하기 위해 사용된다는 점만 알고 하면 문제가 없을 것이다.

 

 

 

여기서 Parameters라는걸 받았다. 이걸 입력 시켜주기 위해 우리는@RequestParam를 쓸것이다. 그리고 Response에서 content의 프로덕트의 내용과 남은 내용이 두가지이기에 ResponseDTO를 두개 만들어줄것이며 [  ]가 있다는건 LIST하라는 소리이기에 product를 LIST하여 totalPage 를 포함한 내용들과 함께 totalResponseDTO를 만들어 줄것이다.

 

 

 

명세서에 보면 category는 선택이다 선택을 할 수 있게 하는게 (required= false)라는 걸 써주면 선택을 할 수 있게 해준다.

 

 

모든 조회를 할때 우리는 카테고리가 있는 경우와 없는 경우를 생각 할 수 있다. 이때 카테고리가 비어있거나 없는 경우네 조건을 써준 후 에 있는 경우를 써준다 두번을 써주는 이유는 컴퓨터는 잘 모르기때문에 자세하게 알려주지 않으면 혼자 이상하게 해석해서 중간에 오류를 낼 수 있기때문이다 그렇기 때문에 하나 하나 알려줘야하낟.

그리고 중간 중간 필요한 함수가 생길때 마다 DAO에 가서 만들어주면되는 것이다. 

 

DAO에서는 모든Product를 불러 올 수 있는 함수와 TotalElements를 불러오는 함수를 만들어줬다. 그중 TotalElements에 return중 Intger.class는 딱 한개의 칸을 불러올때 쓰는 것이다 .

 

 

여기서 RequsetHeader은 다음에 배울 인증 서비스와 관련있는 것이기에 일단은 무시하고 나머지 부분을 진행하겠다.

 

 

위에서 RequsetHeader를 쓰지 않기에 @PathVariable를 써준것이다.

API명세서의 URL을 참고하면 알 수 있다.

 

 

우리는 상품의 자세한 정부를 알 고 싶기에 ProductDetilRespnse를 만든 것이고 이곳에 ProductDAO에서 만든 함수를 이용해 저장할것이다. 리스트로 정리된 reviewList에 는 ReviewDAO에서 만든 함수를 이용해서 저장할것이다 

라는 식이다. 위에서 함수가 필요해지면 DAO에가서 해당 함수를 만들어주면서 작성했다. 마찬가지로 위에 Response가 없다해서 안만든게 아니라 상황에 맞춰서 필요하면 만들어줬다.

 

 

 

 

마찬가지로  RequsetHeader는 넘어가겠다.

URL을 참고하면 만들 수 있다.

 

 

 

리뷰작성시에는 PathVariable과 RequsetBody를 둘다 써준다 PathVariable는 URL을 통해 Path부분을 위해 쓴것이고 RequsetBody부분은 입력자가 입력하는 부분을이 있기에써준것이다.

 

ResponseEntity가 반환하는 데이터의 타입을 유연하게 설정하기 위해서  ResponseEntity의  <  >안 Object를 써준 것이다.

 

 

Service에서는 리뷰의 제약을 걸어주면된다. 유저아이디는 0보다 큰값이어야한다는 아이디의 존재한다면 무조건 프라이머리키를 연결했기에 0보다 작은 값은 이상한 값이다

 

평점은 1~5사이로 남겨야하며 content는 없거나 10글자 미만이면 안된다 이와 같이 이상한 식을 써준뒤에 try catch를 통해 리뷰를 DB에 저장하는 식을 써주면 된다. 이 때 마찬가지로 reviewDAO에 저장하는 식이 없기에 DAO가서 만들어어오면된다

 

 

 

 

 

수정과 삭제 역시 API의 명세서를 보고 필요한 부분들을 참고하여 아래와 같이 쓰면고 마지막 StatusCode를 controller에 써주면 되는 것이다.

 

 

 

Delete는 다음에 할거 맛보기로 RequsetHeader을 쓴 것이지만 안쓰고 한다하여도 크게 다를 것 없기다.

 

 

 

 

아래의 맨 왼쪽 사진과 같이 흐름을 잘 알고 위 문제를 풀면 이해가기가 쉬울 것이다. 하지만 이렇게 본다고 알면 누구나 할 수 있지 않겠는가.. 실제로 이걸 하다가도 흐름을 알면서도 이해가 가지 않았다. 만약 그렇다면 직접쓰면서 하는 걸 추천한다. 위에 사진들이 몇장없고 Response 사진도 복잡해져서 생략해서 그렇지 실제로 처음하면 복잡스럽기에 이해가 되지 않는다면 적어서 하는걸 추천한다. 

 

 

 

'Spring Boot JDBC > 실습' 카테고리의 다른 글

Food리뷰 API 실습 음식점 유저  (1) 2024.12.30
JWT 보안 시스템 설정 실습  (1) 2024.12.27
Spring Boot 를 통한 CRUD 실습  (1) 2024.12.20
SpringBoot 와 DB 터널링 과 실습  (0) 2024.12.19
RequestParam 실습  (0) 2024.12.19