정영진멘토님_멘토링요청서_1222

<aside> ▪️ 2023. 12. 22 (화) 오후 16시 30분~오후 17시 00분 - 정영진 멘토님

</aside>

1️⃣ 프로젝트 현황 공유

<aside> 💡 프로젝트 매니징을 위해 사용 언어, 역할 분담, 프로젝트 진행 현황 등을 우선적으로 공유해주세요

✔️ 원활한 멘토링을 위해 미리 작성해주시면 감사드리겠습니다❗ ✔️ 필요시 이미지/링크/파일 등을 활용해도 좋습니다. ✔️ 멘토링 종료 후, 해당 템플릿을 수정/삭제 하지 말아주세요. 🚫

</aside>

<aside> ▪️ 프로젝트 깃허브 링크 https://github.com/Kernel360/f1-Orury-Backend (백엔드) https://github.com/Kernel360/f1-Orury-Client (프론트엔드_Client) https://github.com/Kernel360/f1-Orury-Admin (프론트엔드_Admin)

</aside>

2️⃣ 멘토링 요청사항

<aside> 💡 ✔️ 질문 내용이나 갯수에는 제한이 없습니다:) ✔️ 효과적인 멘토링을 위해 히스토리, 요청사항 등을 최대한 상세하게 작성해주세요.

</aside>

질문 1

게시글/댓글의 좋아요를 업데이트 하는 컨트롤러인데, 좋아요 생성/좋아요 삭제 컨트롤러를 따로 두는게 나을까요, 하나로 합치는게 나을까요?

형준 의견 : 간단한 기능인데 코드중복이 심해져서, is_like 값을 받아와서 하나로 합치고 업데이트 해주는 게 낫지않나? 복잡한 로직이 아니라서 수정될 일도 없을 것 같다.

민협 의견 : 생성과 삭제의 기능을 분리한다는 측면에서 생각해보면 코드가 중복되더라도 분리하는게 맞는 것 같다.

두 개로 분리한 경우

하나로 합치는 경우 (이전 프로젝트 코드)

질문2

// CommentEntity -> CommentDto
public static CommentDto from(Comment entity) {
        return CommentDto.of(
                entity.getId(),
                entity.getContent(),
                entity.getParentId(),
                PostDto.from(entity.getPost()),
                UserDto.from(entity.getUser()),
                entity.getCreatedAt(),
                entity.getUpdatedAt()
        );
    }

// PostEntity -> PostDto
public static PostDto from(Post entity) {
        return PostDto.of(
                entity.getId(),
                entity.getTitle(),
                entity.getContent(),
                entity.getViewCount(),
                entity.getImages(),
                entity.getCategory(),
                UserDto.from(entity.getUser()),
                entity.getCreatedAt(),
                entity.getUpdatedAt()
        );
    }

// UserEntity -> UserDto
public static UserDto from(SignUpRequest request) {
        return UserDto.of(
                null,
                request.email(),
                request.nickname(),
                null,
                request.signUpType(),
                request.gender(),
                request.birthday(),
                request.profileImage(),
                null,
                null
        );
    }

현재 entity→dto→response, request→dto→entity 등의 dto로 변환하는 작업의 코드가 위와 같이 이루어져 있습니다.

Dto가 record라서 Dto 변환 과정에서 코드 양이 많아지는 것 같습니다.

이렇게 되면, DTO로 변환시키는 오버헤드가 생각보다 많이 발생할 것 같은데, 괜찮은 걸까요?

질문3

2번과 연계된 질문으로, 댓글 정보를 가져오려면 이런식으로 게시글과 유저의 dto도 가져와야 되는데.. 아무리 봐도 계속해서 entity, dto, request, response 간의 변환이 이뤄지다 보니, 오버헤드가 발생해서 너무 발생할 것 같습니다. 컨트롤러에서 바로 리포지토리 때리는 것도 이상하고요.

때문에, 컨트롤러에서 서비스로 보내줄 때 dto가 아닌 request 타입으로 보내주는 게 맞을 것 같은데, 어떻게 생각하시나요?

public record CommentDto(
        Long id,
        String content,
        Long parentId,
        PostDto postDto,
        UserDto userDto,
        int deleted,
        LocalDateTime createdAt,
        LocalDateTime updatedAt
)

private final UserService userService;
private final CommentService commentService;
public ...createPost(request){
		UserDto user = userService.getUser(유저 아이디);
		CommentDto comment = commentService.getComment(댓글 아이디);
		....
		
}

public class UserService {
    private final UserRepository userRepository;

    @Transactional
    public UserDto getUserDtoById(Long id){
        User user = userRepository.findById(id).orElseThrow(()->new BusinessException(UserErrorCode.NOT_FOUND));
        return UserDto.from(user);
    } 
// 이런 식으로 서비스에서 레포 호출하는 메소드 하나 만들기?

dto 사용방식

Untitled

질문4

유효한 댓글인지, 댓글의 작성자가 로그인한 사용자 본인인지 검증하는 로직을 하나로 담아서 처리해도 될까요?

아니면 유효한 댓글 검증 따로, 댓글 본인 여부도 체크하도록 오버로딩 해서 처리하는게 나을까요?

어떤게 좀 더 클린한 코드일까요

질문5

댓글을 조회하는 로직을 작성 중입니다.

사실 댓글은 무조건 게시글 ID가 있는데, 댓글을 조회할 때 게시글 ID가 유효한지 검증하는 것은 오버엔지니어링이라고 판단이 됩니다.

그래도 안정성을 위해서 검증하는 로직을 넣는게 좋을까요?

질문6