DAO와 관련되어 질문이 있습니다.

김승수님 안녕하세요. 🙂

흥미로운 질문해 주셔서 감사합니다.

제가 생각하는 기준을 설명드리도록 할게요.

1. 객체의 모든 필드를 사용하지 않는 경우에도 DAO에서 객체의 모든 필드 값을 채워서 가져오는 것이 좋을까요 ?

a. 만약 경우에 따라 다르게 가져온다면 DAO안에 객체를 가져오는 메소드 수가 많아지는데 이 부분에 대해서는 어떻게 생각하시나요?

이 경우는 두 가지 경우로 나눠서 결정하시는게 좋습니다.

강의에서 설명드린 것처럼 비즈니스 로직을 처리할 목적으로 데이터를 조회하는 경우에는 객체에 필요한 모든 속성을 다 채워야 합니다. 비즈니스 로직을 실행하기 위해서는 객체가 정상적인 상태로 생성되어야 하기 때문에 특정한 필드가 로드되지 않을 경우 잘못 동작할 수 있습니다. 요구사항 변경 시에 코드를 관리하기도 어려워지구요.

비즈니스 로직을 수행하지 않고 단순히 화면 출력을 위해 데이터를 조회하는 경우에는 필요한 필드 값만 채워서 보내는게 좋습니다. 이 경우에는 요청 별로 데이터가 다르다면 다른 조회 메서드를 만드시는게 유지보수 측면에서 더 좋습니다.

2. 이어서 객체와 연관된 Entity를 매핑시켜서 가져오는 부분에 대해서도 연관된 Entity가 필요한 경우와 필요 없는 경우를 나누어서 그에 맞게 가져오는게 좋을까요?

a. 그렇다면 연관된 Entity 내에서 안쓰이는 필드 값이 있다면 안가져오는 것이 좋을까요 가져오는 것이 좋을까요?

이 경우에도 데이터 조회라면 필드와 엔티티 모두 필요한 요소만 조회하시면 됩니다.

비즈니스 로직의 경우에는 로직을 처리하기 위한 캡슐화 경계를 정하고 포함된 엔티티들을 함께 조회하는게 좋습니다.

즉, 로직을 처리하는데 필요한 캡슐화 경계 안에 속하는 요소들은 함께 조회하는게 유지보수 측면에서 좋습니다.

개인적으로 캡슐화 경계의 기준으로 DDD에서 말하는 애그리게이트 패턴을 적용하고 있어요.

애그리게이트와 애그리게이트 사이의 객체들은 연관관계를 끊어서 객체참조로 연결하시고 애그리게이트 내부의 객체는 함께 조회하도록 코드를 작성하시면 됩니다.

애그리게이트에 관해서는 기본 개념은 https://littlemobs.com/blog/ddd-aggregate-basics/ 를 참고해 주시면 좋습니다.

그 외에도 웹을 찾아보시면 많은 양의 자료를 찾아보실 수 있으실거에요.

성능 이슈가 발생한다면 이 경우에 한해서만 지연 로딩이나 별도의 메서드를 추가하시는 방법을 고려해 볼 수 있습니다.

답변이 되었는지 모르겠네요. 🙂