CRUD 다시 보기

2022.08.07 WIL옮겨오기

spring boot로 security를 구현하려다 멘탈이 터져버렸다.
JWT와 spring Security가 만나니 아주 그냥 죽을 맛이다. 이런걸 우째 이해하는걸까..?
이번 주는 이제까지 CRUD를 구현하며 드는 근원적인 궁금점을 한번 적어보려 한다.

CRUD는 뭘까?

CRUD가 뭘까. 코딩창을 들여다보며 API를 만드는 중 갑자기 이런 생각이 들었다.
CRUD가 뭐지? 이게 무엇과 연관이 있을까? 단순히 Create, Read, Update, Delete만 구현하는 건가?
결국 이걸 왜 하는 거지? 내가 CRUD를 구현하는 이유를 곰곰히 생각해봤다.

1.Create

C는 말 그대로 Create다. 웹에서 보내는 값을 DB에 저장하는 역할이다. 보내는 것은 뭘로 보내는 걸까?
RequestDTO를 통해 웹의 입력값을 가져온다. 이걸 받아서 세이브 하는 것이다. Save는 어디서 하지? 이상적으로는 Save, Update와 같은 기능을 Service 클래스에 매서드 형식으로 담아 필요할 때 꺼내 쓰는 것이다. 그럼 Save할 때에는 API를 통해 DTO에서 입력값을 받아 Service 클래스의 특정 함수를 호출해 Repository에 저장한 다음 그걸 Return 해주면 되겠지?

2.Read

Read는 뭘까. Read는 읽는 것. DB에 저장되어 있는 것을 웹으로 쏴서 읽을 수 있게 하는 것이다. 그럼 이것도 DB에서 읽을 수 있는 매서드를 만들어 호출한 다음, 조건에 맞게 Return 해주면 된다. 다만 특정 Id만 가져온다거나 하는 조건이 붙으면 그에 맞는 매서드를 짜줘야한다.

3.Update

얘도 Create 처럼 밖에서 입력값이 들어오는 것이다. 따라서 해당 DTO가 필요하다.
나만 그런가 모르겠는데 Update를 짜는 게 제일 어렵다.
수정한 값으로 Table에 있는 변수가 바뀌어야 하다. 그럼 일단 DTO를 통해 들어온 입력값이 필요하다. 이 값으로 Table의 변수값을 바꿔야 한다. 입력값을 단순히 저장하는 게 아니다. -> 여기서 영속성컨텍스트의  변경감지 개념이 나온다.

일단 맞는 요청이 들어왔나 확인을 해야겠지? 수정은 대체로 {id}를 통해 수정할 대상을 특정한다.
전부 수정하는 요청을 보낼리는 ...없으니까...??
따라서 해당 Id로 접근해서 입력값을 수정될 값과 매칭시켜주는 게 중요하며 그걸 Table로 보내, 선언된 변수가 바뀔 수 있도록 해야 한다.

4.Delete

얘가 제일 좋다. Id를 통해 삭제할 부분을 찾아 삭제해주면 된다

5.이해가 안되던 부분

ResponseDTO가 갑자기 튀어나왔다. 처음엔 이게 이해가 안됐다. 얘는 무슨 역할을 하는 거지? 곰곰히 생각하다 RequestDTO를 생각해봤다. 똑같은 DTO인데 얘가 하는 일은 무엇일까
RequestDTO는 밖의 입력값을 가져오는 것이다. 그게 생성이든 수정이든 일단 밖의 값이니.
그럼 ResponseDTO는 무슨 일을 할까? Response는 반응, 응답, 회신...서버의 값을 웹으로 회신해주는 것이다. 즉 RequestDTO의 역할과 반대라고 이해했다. RequestDTO가 밖의 값을 변수에 맞게 가져오는 것이라면, ResponseDTO는 안의 값을 입맛대로 보여주는 것이다. 그렇게 생각하니 조금 이해가 되는 것 같다.

5.뭘 중점으로 공부할까?

공부의 방향성에 대해서도 생각해봤다. 결국 내가 하는 공부는 일단 DB와 웹 상에서 벌어지는 일을 다루는 것이라고 생각했다. 이렇게 생각하는 게 제일 명료한 것 같다. 그럼 많은 테이블을 다룰텐데, 그 테이블은 분명 복잡한 참조 관계로 이루어져있을 것이다. 따라서 앞으로 나는 테이블 간의 참조관계에 좀 더 집중해 보려 한다.
Security와 JWT는..좀만 기다려라...