이번 Spring 웹 개발을 진행하면서, NormalBoard를 상속받는 다양한 Type의 Board의 CRUD를 전부
설계하는 과정에서 코드 중복, URL mapping등에서 수정해야할 필요성을 느꼈다.
비슷한 맥락의 Board CRUD이지만, 엄연히 따로 존재하는 Entity이기에 Service로직을 따로 가져가야 한다는 점에서 괴리를 느꼈다.
Controller에서 menuId를 기준으로 등록, 수정, 삭제를 해야했으나 다르게 Service 파일을 생성하였고 이에 따라
ContestBoard의 Controller를 따로 설계하는 바람에 menuId Parameter가 따로 존재하는 바람에 menuId의 필요성이 없어지는 상황이 생겼다.
그래서, BoardController로 통합을 하고 제네릭을 사용해서 RequestBody로 유연한 파라미터를 받기로 하였다.
이 기능을 사용해 다양하게 들어오는 dto 객체에 대해 Mapper 클래스를 이용해 menuId에 해당하는 Service를 리턴, 그에 맞는 로직 메소드를 호출하면 된다.
이에 따라 제네릭을 좀 공부해서 코드를 리팩토링 하려고 한다.
현 상황에서 제너릭을 사용해서 리팩토링 하기 위해, 먼저 다양한 dto들을 하나의 BoardParentDto를 상속받는 구조로 만들었다.
그 다음, BoardInterface에서
package com.inhabas.api.service.board;
import com.inhabas.api.dto.board.ParentBoardDto;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
public interface BoardService <T1, T2, T3, T4 extends ParentBoardDto> {
Integer write(T1 saveBoardDto);
Integer update(T2 updateBoardDto);
void delete(Integer boardId);
T3 getBoard(Integer boardId);
Page<T4> getBoardList(Integer menuId, Pageable pageable);
}
다음과 같이 유동적으로 변화시킬 파라미터들을 각각 T1, T2, T3, T4로 정의하였다.
이제 BoardService를 만드는 과정에서 등록, 수정, 단일 조회, 리스트 조회 dto들이 각 제네릭에 지정되어야 할 것이다.
실제 Service 구현체에서는 그 Board Type에 맞는 dto들이 들어가면서 생성된다.
이로서 BoardService 하나의 인터페이스로 구현이 완료되었고,
menuId를 받아 BoardService 구현체를 반환하는 Mapper class를 설계해
BoardController에서 클라이언트로부터 받은 menuId를 기반으로 mapper 클래스를 거쳐 리턴받은 Service Layer에서 메소드를 비로소 호출할수 있게 된다.
'Framework > Spring' 카테고리의 다른 글
[IBAS] Spring MVC의 Handler Mapping 동작 원리 (2) Customizing 편 (0) | 2022.02.15 |
---|---|
[IBAS] Spring MVC의 Handler Mapping 동작 원리 (1) 이론 편 (2) | 2022.02.14 |
MockMVC를 이용한 BoardService 단위 테스트 (JUnit5) (0) | 2022.01.21 |
인프런 스프링 핵심 원리-기본편 #6 빈 스코프 (0) | 2022.01.05 |
인프런 스프링 핵심 원리-기본편 #5 싱글톤 컨테이너 / 의존관계 자동 주입 (0) | 2022.01.05 |