TIL : 서비스 리팩토링

❤️ Today I Learned

기초를 쌓지않으면 언젠가 무너진다
더 노력해야겠다
건강 잘챙기자

📕 내용

• 오늘의 학습 키워드
  - 테스트, 기초, 꾸준함, 노력

@Transactional // 조회 제외하면 transactional 걸어주기  
public PostResponseDto updatePost(Long id, PostRequestDto requestDto) {  
  
    Post post = findPostId(id);  
    post.update(requestDto);  
    Post updatedPost = postRepository.save(post);  
    return new PostResponseDto(updatedPost);  
}

기본적인 update 코드인데 맨처음에는 return 타입을 Entity로 지정했었다.
별거 다를거 없어보였지만 Entity로 지정했을시 발생하는 문제가 존재했다 뭘보내고있는지 알수 있기때문에
보안이슈가 발생한다는 것이였다.

https://simplifyprocess.tistory.com/26

client에 전달해서는 안되는 불필요한 정보가 리턴된다

과거 개인정보 유출보안사고중에서 비슷한 사례가 있었는데, 회원 정보를 제공하는 api에서 회원 db에 있는 모든 정보(Entity)를 그대로 Dto로 만들어서 Client에게 전달했습니다. 그점을 해커가 이용해서 특정 계정으로 인증을 한뒤에
Crawling Script로 회원 api의 파라미터 정보를 바꿔가면서 api를 호출해서 고객정보를 획득해간 사례가 다음에 해당합니다. 하물며 DB Fields = Dto Fields라는 사실입니다.

Entity가 양방향으로 연관관계를 맺고있을경우 무한루프가 발생하며 시스템이 다운된다. <순환참조 오류>

Entity 객체를 json으로 바꿀때 query 실행으로 시스템 부하가 증가한다.

public PostResponseDto createPost(PostRequestDto requestDto, User user) {  
    Post newPost = requestDto.toEntity();  
    newPost.setUser(user);  
    Post savedPost = postRepository.save(newPost);  
    // dto변환  
    PostResponseDto postResponseDto = new PostResponseDto(savedPost);  
    // entity를 사용하고나서 반환해야한다?컨트롤러로  
    return postResponseDto;  
}

entity타입의 변수에 requestDto를 entity화 한다음 반드시 Dto로 변환을 다시 해줘야한다고 한다.

데이터 전송 객체(DTO) 패턴의 일환으로, 프레젠테이션 계층(DTO)과 영속성 계층(엔티티)을 분리하는 데 사용됩니다

이런이유라고 한다.

requestDto를 엔티티로 바꾸고 다시 DTO로 변환하는 이유를 간단히 설명하겠습니다.

1. 엔티티와 DTO의 역할 분리: 엔티티는 데이터베이스와 직접적으로 관련이 있고, DTO는 클라이언트와 상호 작용할 때 사용됩니다. 이 두 가지를 분리함으로써 코드를 더 깔끔하게 유지할 수 있습니다.
2. 비즈니스 로직 적용: 엔티티는 비즈니스 규칙을 담고 있습니다. DTO를 엔티티로 변환하면 데이터를 저장하기 전에 이러한 규칙을 적용할 수 있습니다.
3. 데이터베이스 상호 작용: 엔티티는 데이터베이스와 직접적으로 매핑됩니다. 따라서 엔티티를 사용하여 데이터베이스 작업을 수행할 수 있습니다.
4. 응답 사용자 정의: 데이터를 저장한 후에는 DTO로 변환하여 클라이언트에 응답을 보낼 수 있습니다. 이 과정에서 응답을 사용자 지정할 수 있습니다.