[DAO(Data Access Object)]
repository package
- 실제로 DB에 접근하는 객체이다.
Persistence Layer(DB에 data를 CRUD하는 계층)이다. - Service와 DB를 연결하는 고리의 역할을 한다.
- SQL를 사용(개발자가 직접 코딩)하여 DB에 접근한 후 적절한 CRUD API를 제공한다.
- JPA 대부분의 기본적인 CRUD method를 제공하고 있다.
extends JpaRepository<User, Long>
[DTO(Data Transfer Object)]
dto package
계층간 데이터 교환을 위한 객체(Java Beans)이다.
- DB에서 데이터를 얻어 Service나 Controller 등으터 보낼 때 사용하는 객체를 말한다.
즉, DB의 데이터가 Presentation Logic Tier로 넘어오게 될 때는 DTO의 모습으로 바껴서 오고가는 것이다. - 로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.
하지만 DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. (대신 생성자에서 값을 할당한다.)
Request와 Response용 DTO는 View를 위한 클래스
- 자주 변경이 필요한 클래스
- Presentation Model
toEntity() 메서드를 통해서 DTO에서 필요한 부분을 받아 이용하여 Entity로 만든다.(Request Dto) - 또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.
[Entity Class]
domain package
- 실제 DB의 테이블과 매칭될 클래스
즉, 테이블과 링크될 클래스임을 나타낸다.
Entity 클래스 또는 가장 Core한 클래스라고 부른다.
@Entity, @Column, @Id 등을 이용 - 최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method을 구현한다.
단, Domain Logic만 가지고 있어야 하고 Presentation Logic을 가지고 있어서는 안된다.
여기서 구현한 method는 주로 Service Layer에서 사용한다. - 참고 Entity 클래스와 DTO 클래스를 분리하는 이유
View Layer와 DB Layer의 역할을 철저하게 분리하기 위해서
테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스(Request / Response 클래스)는 자주 변경되므로 분리해야 한다.
Domain Model을 아무리 잘 설계했다고 해도 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있다. 이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 된다.
또한 Domain Model을 복잡하게 조합한 형태의 Presentation 요구사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어렵다.
즉 DTO는 Domain Model을 복사한 형태로, 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용한다.
[Controller(web)]
- Presentation Layer, Contoller를 명시하기 위해서 사용, 웹 요청과 응답을 처리하는 클래스에 사용
클라이언트의 요청을 받음
요청에 대한 처리는 서비스에게 전담
클라이언트에게 응답
기능 - 해당 요청 url에 따라 적절한 view와 mapping 처리
@Autowired Service를 통해 service의 method를 이용
적절한 ResponseEntity(DTO)를 body에 담아 Client에 반환
@controller
- API와 view를 동시에 사용하는 경우에 사용
대신 API 서비스로 사용하는 경우는 @ResponseBody를 사용하여 객체를 반환한다.
view(화면) return이 주목적
@restcontroller
- view가 필요없는 API만 지원하는 서비스에서 사용 (Spring 4.0.1부터 제공)
@RequestMapping 메서드가 기본적으로 @ResponseBody 의미를 가정한다.
data(json, xml 등) return이 주목적: return ResponseEntity
즉, @RestController = @Controller + @ResponseBody
[Service]
- Business Layer, Service를 명시하기 위해서 사용, 비지니스 로직을 가진 클래스에 사용
사용자의 요구사항 처리
source DAO(user) > (Beans_Autowired: new없이 객체생성) > response DTO (controller) - @Autowired Repository를 통해 repository의 method를 이용
적절한 Business Logic을 처리한다.
DAO로 DB에 접근하고 DTO로 데이터를 전달받은 다음, 비지니스 로직을 처리해 적절한 데이터를 반환한다.
[Domain]
클래스를 만들고 이 객체를 담기위한 그릇
[Repository/Dao]
- Persistence Layer, DAO를 명시하기 위해서 사용
DB 관리(연결, 해제, 자원 관리)
DB CRUD 작업 처리 - 실제로 DB에 접근하는 객체이다.
Service와 DB를 연결하는 고리의 역할을 한다.
SQL를 사용(개발자가 직접 코딩)하여 DB에 접근한 후 적절한 CRUD API를 제공한다.
JPA 대부분의 기본적인 CRUD method를 제공하고 있다.
extends JpaRepository<User, Long>
[MVC-M(model, domain) = Dao + Dto]
프로그램이 목표하는 작업을 원활하게 수행하기 위해 필요한 물리적 개체, 규칙, 작업등의 요소들을 구분되는 역할로써 정의해놓은 것
애플리케이션의 정보, 데이터의 가공을 책임지며 DB와 상호작용하며 비즈니스 로직을 처리하는 모듈, 컴포넌트를 말한다.
Client 요청이 들어왔을 때 그 입력을 처리하고 어떤 로직을 실행시킬 것인지 제어하는 모듈
[MVC-V(view)= JSP, JSTL]
Client에게 보여지는 결과화면을 반환하는 모듈
View를 가리키고 사용자가 보는 화면에 입출력 과정 및 결과를 보여주기 위한 역할을 한다. 입출력의 순서나 데이터 양식은 컨트롤러에 종속되어 결정되고, 도메인 모델의 상태를 변환하거나, 받아서 렌더링하는 역할(절대적으로 객체를 전달받아 상태를 바로 출력하는 역할만을 담당). view에서는 도메인 객체의 상태를 따로 저장하고 관리하는 클래스 변수 혹은 인스턴스 변수가 있을 필요가 없다.
[MVC-C(controller)=service+controller]
DB와 상호작용하며 비즈니스 로직을 처리하는 모듈
controller는 하나일 필요가 없다. 프로그램이 실행될 때 로직이 병렬적으로 분기된다면 controller를 여러개 둬도 상관없다.
MVC의 뷰는 여러 개의 컨트롤러(Controller)를 가지고 있다. 사용자는 컨트롤러를 사용하여 모델의 상태를 바꾼다. 컨트롤러는 모델의 mutator 함수를 호출하여 상태를 바꾼다. 이때 모델의 상태가 바뀌면 모델은 등록된 뷰에 자신의 상태가 바뀌었다는 것을 알리고 뷰는 거기에 맞게 사용자에게 모델의 상태를 보여 준다. - wikipedia-
