📚 DTO - Data Transfer Object

DB의 데이터를 담고 전송하는 데 사용되는 객체이며 로직을 포함하지 않는 순수한 데이터만 담는 객체임

🌱 DTO 장점

• 어떤 데이터를 전송하고, 데이터를 담는지 명확하기 때문에 복잡하고 큰 프로젝트에서 식별하는데 용이함.
• Client의 요구사항이 변경되어도 DTO만 수정하면 되므로 서비스 로직, DB계층(Entity)에 변경 없이 대응가능 함

📚 DAO - Data Access Object

DB에 직접적으로 접근하는 객체이며 주로 CRUD 작업을 처리한다.
DAO는 DB와 상호작용하며 비즈니스로직과 DB사이를 이어주는 징검다리 역할을 한다.

🌱 DAO 장점

• 일관된 interface를 제공하여 재사용이 용이하고, 확장이나 변경에 유리함.
• 서비스 로직과 DB접근 로직을 분리하여 결합도를 감소시킨다.
• 서비스 로직의 대한 단위테스트시 오직 서비스로직에만 테스트를 가능하게 한다.

📚 DAO를 왜 사용하는 걸까?

관통 프로젝트를 진행하면서 가장 큰 의문점을 가졌던 부분이다
위 코드는 서비스 로직에서 DAO를 통해 쿼리문으로 DB에서 데이터를 가져오고 가져온 데이터를 DTO에 담는 예제코드이다.
처음 든 생각은 그냥 서비스 로직 구현체에서 DAO의 역할을 부여하면 되지 않을까? 였다.

하지만 DAO가 없다면 이러한 문제점이 발생할 수 있다.

1. 서비스 로직이 원래의 역할이 아닌 DB상호작용까지 책임을 지게 된다면 DB에 의존적으로 구현한다.
2. 단위 테스트시 서비스로직테스트 시 DB까지 함께 테스트하게 되어 DB상태가 테스트 결과에 영향을 미친다.

결국 결합도의 증가로 이어져 확장에 유연하지 못하고 복잡한 구조를 가지게 된다.

🚨 결론

미래를 위해서 DTO, DAO를 사용하자!