DTO 사용 형식에 대한 논의

[unikal1]

DTO를 어떤 방식으로 사용할지에 대한 논의입니다.

• 가독성이 좋고, 너무 많은 클래스 파일을 발생시키지 않아야 한다.
• 복잡한 구조를 피하되, 중복을 최대한 줄여야한다.

제안 1

inner class를 사용

public class MemberDto {
    @Builder
    @Getter
    public static class Create {
        private String username;
        private String password;
        private String name;
    }
    @Builder
    @Getter
    public static class Update {
        private String password;
        private String name;
    }
}

과 같이 사용한다.
장점 : 비슷한 역할을 하는 dto를 하나의 클래스 파일에 몰아 넣음으로서 사용이 간편하고 가독성이 뛰어나다. 파일 자체가 줄어든다.

제안 2

모든 DTO를 하나의 클래스 파일로 수정

장점 : 직관적이고 구현 상의 어려움이 존재
단점 : 파일 수가 너무 많아짐

제안3

공통된 필드에 대한 getter 메서드 인터페이스를 선언하고 이를 상속하여 dto를 구현

public interface MemberDto {
    String getUsername();
    String getPassword():
    String getName();
}

@Getter
public class CreateMemberDto implement MemberDto {
    private String username;
    private String password;
    private String name; 

    public CreateMemberDto(String username, String password, String name) {
        this.username = username;
        this.password = password;
        this. name = name;
    }
    
    @Override
    public String getUsername() {
        return username;
    }
    @Override
    public String getPassword() {
        return password;
    }
    @Override
    public String getName() {
        return name;
    }
}

@Getter
public class UpdateMemberDto implement MemberDto {
    private String username;  //actually no used
    private String password;
    private String name; 
    
    public UpdateMemberDto(String password, String name) {
        this.password = password;
        this. name = name;
    }
    
    @Override
    public String getUsername() {
        return "no username while update";
    }
    @Override
    public String getPassword() {
        return password;
    }
    @Override
    public String getName() {
        return name;
    }
}

장점
실수에서 비롯되는(잘못 호출하는 get 메서드 등) NPE 방지 가능
원론적으로 엔티티로부터 모든 필드에 대한 get 메서드를 선언해놓음
단점
근데 결국 클래스 파일은 많아진다.

[s0o0bn]

일단 먼저 3번은 모든 DTO가 무조건 안쓰는 필드도 갖고 있어야 한다는 점에서 그닥 적절하지 않은 거 같습니다

[s0o0bn]

저도 저 방법은 좋다고 봅니다 정희님이 말한 생명주기는 좀 생각을 해봐야 할 거 같네요

[unikal1]

nested static record의 경우, 우리가 생각하는 보편적인 객체와 GC가 동일하게 작동되는거 같네요. 즉, 결국 사용되는건 outer class의 인스턴스로 생성을 하니까요.

OuterClass oc = new OuterClass.NestedRecord("data");

처럼 선언해서 사용하니까요.
내부 필드가 static이 아니라면, static 남발에 의한 메모리 누수 문제는 없는거 같아요.
생명주기가 다르다는 의미는 결국 로드 시점에서 outer 객체와 서로 다른 로드 시점 및 GC 시점이 다르다 정도로 보면 될거 같은데 맞나요.

[s0o0bn]

그런데 지금 하나 이슈가 IDE로 위 코드처럼 선언해봤는데 컴파일 에러가 뜨네요
생각해보니 저 두 클래스가 상속 관계가 아니라서 저 방식의 선언은 불가능한 거 같습니다 (record 아니고 그냥 class도 동일합니다)

근데 이렇게 되면 만약 위 예시 상황에서 매번 변수 타입을 MemberDto.Create로 가지고 가거나 (변수 선언, 함수 파라미터 등등)
아님 그냥 Create로 해야할 텐데 뭔가 이게 적절한 방식인거 같지는 않아 보이네요 🤔 특히 후자는 더,,

제 생각에는 DTO 클래스 파일이 많아지는 건 어쩔 수 없는 건가 싶기도 한데,
사실 이 부분에 대해서 각각 단일 record 파일 외의 방법을 고려해본 적이 없어서 잘 모르겠네요

[sjhlko]

근본적으로 DTO의 존재 의의는 Entity 객체의 정보 손상 방지도 있지만 클라이언트-서버 간의 통신에 필요한 필드들을 담아 옮길 형태(껍데기)로서 사용됩니다
때문에 각 필드들이 같은 엔티티의 속성이면서 이름과 의미가 같다고 해도 엄연히 다른, 별개의 필드라고 생각합니다
예를 들어서 create 동작을 위한 DTO의 username 과 update 동작을 위한 DTO의 username의 경우,
전자는 생성할 유저의 이름 이고, 후자는 유저의 기존이름을 대체할 새로운 이름 인 것처럼 말입니다.

때문에 그것들을 한곳에 모아 관리하는건 당연히 개발자 입장에서 유지보수, 코드 관리, 중복 DTO 생성 사전 방지 등 여러 장점이 있다고 생각하지만, 단순히 파일 개수가 늘어난다는 이유로 각 DTO를 모조리 한곳에 모아야만 한다는건 주객전도라고 생각합니다.

결론적으로 이 때문에 저는 각 기능에 맞는 DTO를 개별 레코드로 관리하되, 명명 규칙을 사전에 정의한대로 따르고 (updateUserReq 등) 이들이 너무 산개되어있지 않게 dto 디렉토리에 도메인별 하위 디렉토리를 둬서 관리하곤 했습니다.

정답은 없다고 생각하지만 OOP를 너무 의식하여 오히려 코드가독성이 떨어지거나, 코드 길이가 너무 길어지는 등 개발 속도의 저하가 우려되는 경우에는 이를 지양해야된다고 생각하는 편입니다.

[unikal1]

그러면 여러 개별 레코드로 관리하되, 명명 규칙 및 주석을 조금 확실하게 적는 방안으로 가보죠. 아 그리고

OuterClass.NestedRecord t = new OuterClass.NestedRecord();

가 맞겠네요