24.07.22
today 😉
[DTO를 어느 계층까지 써야하고 어느 계층 부터 Entity를 사용해야 하는가❓ at. Spring]
DTO가 Controller 까지 라는 의견은, 클라이언트의 요청 데이터 형식을 Service 계층은 몰라야한다는 것이 근거였다.
Service 까지 라는 의견은, Repository에서만 사용되는 Entity 객체를 Controller 계층은 몰라야한다는 것이 근거였다.
많은 주장이 있지만, 두 주장을 모두 충족하려면 각 계층 별로 따로 사용되는 DTO 객체를 각각 둔다면 모두의 뒷받침 할 수 있을 것 같고 더 모듈화한 코드가 될 수 있다고 생각한다.
하지만 언제까지나 정답이 없고 오버엔지니어링을 하게 된다면 결코 좋은 코드라고 말할 수 없을 것 같다. 프로젝트 규모별로 최선의 아키를 짜고 적합한 설계를 하는 것이 가장 좋은 설계인 것 같다.
[로그인을 GET요청이 아닌 POST 요청으로 해야하는이유가 무엇 일까❓]
로그인 과정에서는 사용자의 개인정보가 포함된 데이터를 안전하게 전송해야 한다.
GET요청으로 사용자의 데이터를 URL에 포함하여 전송한다면 사용자 개인정보가 URL에 노출 될 것이다. 이를 위해 POST 요청을 사용하여 HTTP body에 데이터를 넣어 전송하는 것이 보안적으로 더 안전하며, SSL/TLS HTTP body를 암호화함으로써 네트워크 통신에서 보안성을 강화할 수 있다.
이와 같은 이유로 로그인과 회원가입 등 사용자의 개인정보를 다루는 네트워크 통신에서는 POST를 사용해야 한다고 생각한다.
[DTO 왜 사용해야 하는가❓]
클라이언트에게 전달되지 않아도 되는 데이터를 포함하게 된다.
Entity를 모든 계층에서 전역적으로 사용하게 된다면 클라이언트의 요청을 받는 데이터 객체, Service에서 비즈니스 로직에 사용되는 객체, DB와 연동하는 객체 많은 역할을 하게 되기 때문에 많은 Actor가 관여하게 되기 때문에 SRP를 위반하게 된다.
컬럼이 많은 DB 매핑 객체 자체를 네트워크 응답 객체로 사용하게 될 시 네트워크 비용이 올라가게 된다.
DB 컬럼명 변경시 클라이언트 요청 매핑자도 바껴야 한다.
위와 같은 이유로 DTO를 사용하여 클라이언트와 서버 간의 데이터 전송을 효율적으로 관리할 수 있게 되고 확장성을 고려한 설계를 할 수 있다고 생각한다.
[DB 왜 쓰는가❓]
보안적으로는 데이터 접근 제어와 암호화를 통해 데이터를 안전하게 보호하여 보안을 유지할 수 있다.
그리고 데이터의 일관성과 정확성을 유지하여 신뢰할 수 있는 정보를 제공함으로써 데이터 무결성을 보장할 수 있다.
위와 같이 크게 두가지 이유로 DB를 사용한다고 생각한다.
사용할때, 빠르고 쉽게 그리고 효율적으로 쓰고 찾고 싶어서
중복 안전/보안
데이터를 신뢰할수 있도록 해준다.
검증된 데이터가 체계적으로 모여있어서(= 중복X, 보안, 정확, ...) 나중에 사용할때, 효율적으로 데이터를 찾아서 쓸 수 있는 공간
