[TIL#25-1] 가을에 시작한 Spring <PLUS 복습>

1. 12/12 과제

 1) 닉네임, 비밀번호, 비밀번호 확인을 request에서 전달받기

 

 작성하다가 문득 이런 생각이 들었다. 그냥 단순히 메세지와 상태코드만을 반환하는데 굳이 Dto가 필요할까?

• 현재의 나는 Dto를 프로세스 간에 데이터를 전달하는 용도로 사용하며 비즈니스 로직을 포함하지 않는 데이터를 전달하기 위한 단순한 객체로 알고 있다. 이렇게 하는 이유는 보여주고 싶은 정보를 따로 선택해서 보여줄 수 있기 때문이다.
  
  
• 근데 그냥 위의 경우처럼 단순한 정보를 돌려줄거면 enum을 만들고 그냥 Dto 형태가 아닌 ResponseEntity<String>으로 돌려보내줘도 괜찮을까? 결론은 안될 것 같다. 이유는 통일성도 있고, Dto로 넘겨주는 것이 컨벤션에 맞기 때문이다. 그렇다고 저렇게 "회원가입 성공" 형태 그대로 만들면 안될 것 같다는 느낌이 강하다. 그렇다면 어떻게 해야하냐?

enum 을 만들고

 

 

Dto 클래스에서 사용해주면 

 

 

enum으로 만든 공통코드와 공통Dto를 함께 세트로 사용하면 고민했던 문제가 해결된다.

 

2) 회원가입 이전 아이디 유효성 검토

 고민거리는 3개였다.

• 새로운 API 를 따서 하는 방법 밖에 없는가?
• API 메서드는 Post 와 Get 중 어떤 것을 사용해야할까?
• Dto 는 따로 만들어야하나?

일단 새로운 API를 따는 방법을 택하고 Post 메서드를 사용했다.

 이유는 어찌됐건 입력된 정보를 받고 그 정보를 굳이 외부에 노출시키지 말고 바디에 숨기고 싶 때문에 Post메서드, 받은 정보로 로직을 돌리는 것이기 때문에 해당 로직에 대응하는 API가 필요하다 판단했다. 그리고 사실 API를 따는 방법 말고 다른 방법을 모른다는 함정도 있다.

 마지막으로 Dto를 따로 만드는 것이 좋은가? 이다. 분명 Dto를 세분화 하는 것은 권장되는 것이라고 생각한다. 하지만, '과도하게 많은 Dto는 문제가 있지 않을까?' 하는 생각이 들었다.

 현재 만드는 프로젝트는 Dto를 새로 만들어도 문제가 없지만 만약에 사이즈가 큰 프로젝트를 할 때, 그저 사소한 정보의 더블체크에 불과한 기능을 만드는 것에도 Dto를 파야하는 고민이 생겼다. 일단 Dto를 새로 파서 했지만, 아직 고민은 여전히 남아있다.