간단한 프로젝트를 진행하며, DTO, DAO, Entity와 관련된 개념이 나왔다.
사실 Controller, Service, Repository를 사용하며 자바 스프링이 알아서 잘 해주다보니 이런 부분을 모르고 그냥 뭣도 모르고 갔다 썼는데 이참에 개념을 정리해본다.
먼저 다음과 같은 전체적인 구조를 살펴보자. 먼저 간단히 개념을 설명한 뒤, 이후 Entitiy, DTO, DAO에 대해 정리하겠다.
Client부터 Repository까지는 순수하게 데이터의 이동만을 위한 DTO(Data Transfer Object)로 데이터가 전달됨.
(데이터는 가지나 로직은 없음)
Repository를 통해서 실제 DB와 연동될 때, Entitiy형태로 데이터를 주고 받게 됨.
(DB의 한 테이블 그 자체)
실제 데이터에 접근해서 변경하는 부분은 Repository 객체이므로, 이러한 Repository가 바로 DAO(Data Access Object)임.
(엄밀히 말하면 DAO와 Repository는 다름)
데이터 베이스의 테이블을 클래스로 나타낸 Entitiy는 실제 데이터베이스의 한 테이블과 동일하므로 Domian이라고 할 수 있음.
이 단어는 들을때마다 자꾸 르세라핌의 antifragile가 생각난다...
엔티티티....안티티티티...
🤔 Entitiy란 무엇일까?
간단히 정의하자면 데이터 베이스 내 한개의 테이블을 나타내는 객체이다.
데이터베이스와 1:1로 매핑되며, DB에 존재하는 Colunm(Attribute)를 멤버로 가진다.
바로 예시를 보자.
BookStore라는 데이터베이스가 있고, 이 데이터베이스는 현재 Book이라는 테이블을 가진다.
테이블 내 Attribute는 다음과 같다.
🤔 이 때, 이 데이터베이스 테이블을 나타내는 Entitiy는 어떻게 생겼을까?
➡ DB와 똑같다! DB에 존재하는 Column과 동일한 멤버를 가지므로 다음과 같다.
스프링 JPA를 사용해서 현재 DB를 조작하고 있으므로,@Entity
어노테이션이 붙었고, id값의 경우, 자동으로 증가시키기 위해서@GeneratedValue
를 사용했다.
단순히 데이터를 전달하기위한 객체이다.
즉, 데이터베이스에 접근하지 않고 Client, Controller, Service, Repository간 데이터를 주고받을 때 사용되는 객체를 DTO라고 할 수 있다.
그냥 Entitiy 쓰면 되는 거 아닌가요?
데이터를 주고 받기위해서 DTO를 사용하는 것은 알겠는데, 그럴 빠에 기존 Entitiy를 사용해서 테이블 자체를 주고 받으면 더 편리한 것이 아닐까?
앞서 서술했듯, Entitiy는 Repository와 실제 DB간에 데이터를 주고 받을 때 사용되는 객체이다.
객체를 표현하기 위한 계층과 저장하는 계층의 역할은 분리되어야한다.
또한 View와 통신하는 DTO 클래스는 자주 변경되므로 DB에 종속적인 Entity와는 분리되어 사용되야아 한다.
또한 DTO로 분리해서 사용하게 됨으로써 Entity객체의 데이터의 변질또한 방지할 수 있다.
DAO는 실제로 DB에 접근하는 객체이다.
딱 보자마자,
DB 접근 및 CRUD 수행 ➡ Repository 가 떠오른다.
JPA의 경우 쉽게 Reposiroty라고 생각하면 되는데, 사실 Repository = DAO는 아니다.
상세한 내용은 출처를 참고.
Controller는 Client의 요청을 DTO의 형태로 받아 Service의 기능을 호출하고, 적절한 응답을 DTO의 형태로 반환하는 역할을 한다. 즉, 요청과 응답을 관리하는 계층이라고 생각하면 된다.
Service 계층은 DTO를 통해 받은 데이터를 이용해 비즈니스 로직을 처리하고, DAO(혹은 Repository)를 통해 DB에 접근하여 데이터를 관리하는 역할을 한다.
Service가 DB에 접근을 위해서, Repository라는 DAO를 사용한다고 생각하면 쉽다.
JPA를 사용하면 Repository를 통해 DB에 실제로 접근할 수 있다. Service와 DB를 연결해주는 역할을 하며, Service 계층에서 Repository를 이용하여 데이터를 관리할 수 있다.
[출처] : 출처
Entitiy 스펠링 틀렸어요 !