오늘
- Spring 서비스 계층
서비스 계층
서비스 계층은 비스니스 로직을 처리하기 위한 계층이다.
어제 작성한 코드에는 Member, Coffee, Order 의 Controller와 Dto가 있을 것이다.
MemberController 클래스에서 어떤 서비스가 필요한지 보자.
Post = 회원가입
Patch = 회원정보 수정
Get = 회원 조회
Delete = 회원 삭제 (탈퇴)
가 될 것 이다.
그걸 코드로 적으면
@Service = Spring Bean 으로 등록.
new Member(memberId, "hgd@gmail.com", "홍길동", "010-2222-1111");
이렇게 몇번 실행해도 똑같은 값이 나오는 것을 Stub 데이터라고 한다.
원래는 return 값에 DB가 들어와야하지만 우리는 아직 배우지 않았으므로 그냥 동일 값 리턴.
그리고 Member는 MemberService 에서 필요한 데이터를 담는 역할을 한다.
즉 서비스 계층과 데이터 액세스 계층을 연동하며 필요한 데이터를 가져오는 클래스를 Entity(엔티티) 클래스라고 한다.
Entity의 구조
애너테이션 설명은 사진 참고.
엔티티 클래스 객체를 보면 MemberPostDto, MemberPatchDto 에 있는 객체가 다 모아진 것을 알 수 있다.
DI를 통한 서비스 계층과 API 계층 연동
DI 방법은 크게 두 가지로 나눠진다.
1. 생성자 주입
생성자가 하나인 경우 @autowired 생략 가능.
보통 final 키워드를 이용해서 표시.
2. Setter 주입
중간에 ID 주입 객체를 변경해야 할 경우 사용. (흔하진 않는다고 함)
위 코드에서는 생성자 주입으로 값을 넣고 있다.
MemberService 객체는 Spring 이 애플리케이션 로드시 ApplicationContext 에서 찾아 주입 해준다고 한다.
그러므로 주입 받을 클래스와 주입 할 클래스 모두 Spring Bean에 등록이 되어있어야 한다.
Service 클래스만 사용했을 때 문제점
- Controller 핸들러 메서드의 역할 분리 안됨.
지금 Controller 핸들러에서는 DTO 클래스를 Entity 객체로 변환까지 해주고 있음. - 서비스 계층에서만 사용되는 Entity 클래스를 클라이언트 응답으로 전송하고 있다.
DTO와 Entity의 생긴 이유
DTO : 클라이언트의 요청(Request)을 하나의 객체로 한번에 받기 위해 생겼다.
Entity : 비즈니스 로직을 처리하는데 사용하는 클래스. 이후에 DB와 연관됨.
Mapper
아까 같은 상황을 만들지 않기 위해 DTO 클래스를 Entity 로 변환해 주고, Entity 클래스를 다시 DTO로 변환해주는 누군가가 필요한 상황이다.
그럴때 사용하는게 Mapper(매퍼).
@Mapper(componentModel = "spring") = 자동으로 Spring Bean 등록.
1번째 MemberPostDto를 Member(엔티티) 로 변경.
2번째 MemberPatchDto를 Member(엔티티) 로 변경.
3번째 Member(엔티티)를 Dto로 변경.
3번째 MemberResponseDto는 응답을 하는 DTO다.
클라이언트에게 응답을 전달해 줄 DTO.
코드를 보면 이렇다.
마지막으로 Controller에 적용해주면
굉장히 깔끔해진 코드가 된다.
@Mapper 인터페이스
아까 @Mapper 인터페이스에서 DTO를 Entity로 변경해주고, Entity를 DTO로 변경해줬는데
어떻게 가능하냐면.
Mapper 애너테이션은 MapStruct 안에 속해있는데
이 MapStruct가 MemberMapper 인터페이스를 기반으로 Mapper 구현 클래스를 자동으로 생성해준다.
자동으로 생성된 구현 클래스는
이렇게 생겼다.
Project -> 프로젝트 명 -> build 디렉토리안에 MemberMapper 가 있는 패키지에 생성됨.
