스프링 DTO 명명 규칙

Question

물론 회사 별, 개인차 별 천차만별인 건 알고 있습니다만..이전 프로젝트에서 ...Request, ...Response로 각각 DTO 클래스를 따로 뒀다가다른 분이 하나의 클래스 내에서 Request, Response 객체를 static으로 따로 두는 것을 보고좋아 보여서 따라 하다가 좀 난관 아닌 난관에 부딪혔네용예를 들면 GET 요청으로 하는 Response 의 경우Request로 받지 않고 파라미터 등으로 받기 때문에 Request 내부 클래스는 없을 텐데이런 경우 내부에 Request도 빈 것으로 만들어두어야 하는 건지.. Response 내부 클래스만 만드는 것인지..아니면 이런 경우엔 그냥 A.Response 가 아닌 A 자체로 Response를 대체하는 것인지..아니면 Response만 있는 클래스의 경우 아예 클래스 명을 AResponse로 작성해야 하는지..또, 다른 Request에 대해 같은 형식의 Response 클래스를 반환할 경우 (예를 들면 JWT 토큰이라든지)위와 비슷하게 B.Request를 받아 A.Response를 반환하는 것이 좀 이상해 보이기도 하고..? 그렇네용다채로운 여러분의 의견을 듣고 싶습니다! 여러분은 어떤 형식을 사용하시는지,Request, Response를 따로 만들면 물론 제일 쉽게 해결되긴 하겠지만 만약 위와 같은 방법 (A.Request, A.Response)으로 DTO를 만든다면 위에 제가 질문한 부분에 대해선 어떻게 대처하시는지 궁금합니다..!!!!!

kenu,전독시 · Answer

Clean Architechture의 역발상이네요. request와 response는 웹이라는 컨텍스트에 맞물려 있기 때문에, 가급적 Service나 DAO로 보내지 않는 것이 좋다고 배웠습니다. 그래서 Data Transfer Object가 필요하죠.뭐, 그리 복잡한 시스템이 아니면 돌아가면 좋다고 봅니다.

스프링 DTO 명명 규칙

1개의 답변

기술 목록