[마켓 브릿지 프로젝트] 카테고리 기능 구현 2. 전체 카테고리 목록 조회 API, 계층형 구조 처리 (QueryDsl 재귀 쿼리, NestedConvertHelper)

지난 포스팅에 이어 이제 실질적으로 어떻게 코드를 짠 건지 정리해보도록 하겠다.

우선, 개발환경은 JAVA 17, gradle, Spring 3.2.1 이러하다.

 

1. 필요한 API 목록 정리

A. 전체 카테고리 목록 조회 API

첫 메인 화면에 진입하면 가장 먼저 전체 카테고리를 조회하게 된다.

B. 특정 카테고리의 하위 카테고리 목록 조회 API

만약 "의류" 카테고리라면 그 하위에 존재하는 티셔츠, 맨투맨/후드티 등등의 하위 카테고리 목록이 필요하다.

 

2. 전체 카테고리 목록 조회 API 구현

카테고리 부분 실제 구현한 디렉토리 구조이다.

 

A. REQ/RES 형태 정의

GET 요청으로 /category/total 이 들어온다면,

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 614

{
  "code" : 200,
  "status" : "OK",
  "message" : "OK",
  "data" : [ {
    "categoryId" : 1,
    "parentId" : 1,
    "level" : 1,
    "name" : "TEST CATE1",
    "childCategories" : [ {
      "categoryId" : 2,
      "parentId" : 1,
      "level" : 2,
      "name" : "TEST CATE1",
      "childCategories" : [ {
        "categoryId" : 3,
        "parentId" : 2,
        "level" : 3,
        "name" : "TEST CATE1",
        "childCategories" : [ ]
      }, {
        "categoryId" : 4,
        "parentId" : 2,
        "level" : 3,
        "name" : "TEST CATE1",
        "childCategories" : [ ]
      } ]
    } ]
  } ]
}

이런 식의 형태로 반환할 계획이다.

정리하자면, childCategory라는 값의 리스트 안에 하위 카테고리 정보들이 있고 이런 형태이다.

 

B. 카테고리 도메인 엔티티 설정

@Entity
@Getter
@NoArgsConstructor
public class Category extends BaseEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "category_id")
    private Long id;

    @ManyToOne()
    @JsonIgnore
    @OnDelete(action = OnDeleteAction.CASCADE)
    @JoinColumn(name = "parent_id",referencedColumnName = "category_id",insertable=false, updatable=false)
    private Category parent;

    @Column(name = "parent_id")
    private Long parentId;

    private Long level; //대분류 1L, 중분류 2L, 소분류 3L.
    private String name;

    @Builder
    private Category(Long id, Long parentId, Long level, String name, Category parent) {
        this.id = id;
        this.parentId = parentId;
        this.level = level;
        this.name = name;
        this.parent = parent;
    }

    public void setParentId(Category category){
        this.parent = category;
    }
}

1. 하나의 상위 카테고리는 여러개의 하위 카테고리를 가지고 있을 수 있다.

엔티티 관계 관점으로 보면 자식 엔티티부터 존재하고 거꾸로 부모 카테고리와의 연관 관계를 심어주는 순서가 된다.

따라서 ManyToOne으로 같은 타입의 변수를 parent로서 선언해준다.

parentId가 따로 또 존재하는 이유는 뒤에 가서 설명하도록 하겠다.

 

2.  Builder 패턴을 활용해서 엔티티 생성시 파라미터 순서를 고려하지 않아도 되도록 구현

객체를 생성할때 생성자를 통해 생성을 하게 되는데, 이때 생성 메소드 파라미터의 순서를 지켜야한다.

근데 builder 어노테이션을 붙여서 builder 패턴을 사용하게 되면 순서를 고려하지 않고, 변수 이름으로 매칭하여 생성할 수 있다.

request / response 과정에서 코드의 간결함과 재사용성을 위해 Dto를 이용해서 데이터를 주고 받았다.

이때도 Dto를 빌더패턴으로 생성하게 구현했는데,

    public static CategoryDto of(Category category){
        return CategoryDto.builder()
                .categoryId(category.getId())
                .parentId(category.getParentId())
                .level(category.getLevel())
                .name(category.getName())
                .build();
    }

 이런식으로 사용될 수 있다.

 

3. BaseEntity 상속으로 코드 재사용성 증가

@EntityListeners(AuditingEntityListener.class)
@MappedSuperclass
@Getter
public abstract class BaseEntity {

    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;
    private LocalDateTime deletedAt;

}

DB에 각 테이블마다 생성일자, 수정일자, 삭제일자가 들어가게 되는데, 코드 재사용성과 유지보수를 위해 BaseEntity로 묶고, 해당 클래스를 상속받도록 처리했다.

 

C. Dto 설정

@NoArgsConstructor
@Getter
public class CategoryDto {

    private Long categoryId;
    private Long parentId;
    private Long level;
    private String name;
    private List<CategoryDto> childCategories;

    @Builder
    public CategoryDto(Long categoryId, Long parentId, Long level, String name) {
        this.categoryId = categoryId;
        this.parentId = parentId;
        this.level = level;
        this.name = name;
        this.childCategories = new ArrayList<>(); // 빈 배열로 초기화
    }

    public static CategoryDto of(Category category){
        return CategoryDto.builder()
                .categoryId(category.getId())
                .parentId(category.getParentId())
                .level(category.getLevel())
                .name(category.getName())
                .build();
    }

    public void addChildCategories(CategoryDto categoryDto){
        childCategories.add(categoryDto);
    }

    public void addChildCategories(List<CategoryDto> categoryDto){
        childCategories.addAll(categoryDto);
    }
}

DB와 매칭되는 도메인 엔티티 테이블만으로 사용하게 되면 코드단에서 데이터를 주고 받을 때마다 변형시키는 작업이 필요하게 된다.

1. 유지보수와 코드 재사용성을 위해 CategoryDto 사용

- Category 엔티티 테이블을 직접 건들지 않고, Dto를 통해서 접근하거나, 변형하도록 설계하였다.

- CategoryDto의 of 메서드를 추가하여 Category엔티티의 구성요소를 하나하나 알지 못하더라도 객체만 집어 넣으면 바로 Dto객체로 변환시켜주도록 설계하였다.

 

2.  반환 데이터 규격 기준으로 Dto 변수 선언

반환 데이터를 설정한 기준대로 변수를 선언하고, List<CategoryDto> 타입으로 재귀적인 구조를 구현하였다.

 

D. controller 구현

@RestController
@RequiredArgsConstructor
@RequestMapping("/category")
public class CategoryController {

    @Autowired
    private final CategoryService categoryService;

    //조회
    @UserAuthorize
    @GetMapping("/total")
    public ApiResponse<List<CategoryDto>> getTotalCategories() {
        return ApiResponse.ok(categoryService.getTotalCategories());
    }
}

1. 코드 재사용성과 유지보수의 편의를 위해 ApiResponse 객체 사용

@Getter
public class ApiResponse<T> {

    private int code;
    private HttpStatus status;
    private String message;
    private T data;

    @Builder
    private ApiResponse(HttpStatus status, String message, T data) {
        this.code = status.value();
        this.status = status;
        this.message = message;
        this.data = data;
    }

    public static <T> ApiResponse<T> of(HttpStatus httpStatus, String message, T data) {
        return new ApiResponse<>(httpStatus, message, data);
    }

    public static <T> ApiResponse<T> of(HttpStatus httpStatus, T data) {
        return of(httpStatus, httpStatus.name(), data);
    }

    public static <T> ApiResponse<T> of(HttpStatus httpStatus) {
        return of(httpStatus, null);
    }

    public static <T> ApiResponse<T> ok(T data) {
        return of(HttpStatus.OK, data);
    }

    public static <T> ApiResponse<T> create() {
        return of(HttpStatus.CREATED);
    }

}

기본적인 code, status, message, data의 변수로 구성되게 설정하였다.

따라서 service단에서 넘어온 데이터 결과를 ok 상태값과 함께 List<CategoryDto>타입의 값을 data 변수안에 넣어서 반환하는 것이다.

 

E. CategoryService 구현

@Service
@Transactional(readOnly = true)
public class CategoryService {

    private final CategoryRepository categoryRepository;
    private final CategoryCustomRepository categoryCustomRepository;

    @Builder
    public CategoryService(CategoryRepository categoryRepository, CategoryCustomRepository categoryCustomRepository) {
        this.categoryRepository = categoryRepository;
        this.categoryCustomRepository = categoryCustomRepository;
    }

    public List<CategoryDto> getTotalCategories() {
        List<Category> categoryList = categoryCustomRepository.findAllOrderByParentIdAscNullsFirstCategoryIdAsc();
        return CategoryDto.toDtoList(categoryList);
    }
}

- 최대한 Service에는 핵심 비즈니스 로직만을 담고 싶었다.

- Service 단에서 데이터를 가공하는 등(단순히 객체 -> 객체 리스트로 변환하는 작업)의 행위를 하게 되면 유지보수 측면에서 좋지 않다고 생각했기 때문이다.

- 내가 생각한 핵심 비즈니스 로직이란 데이터베이스가 변경되거나 Req,Res 규격이 변경되어도 변하지 않는 로직이다.

예를 들자면 요리를 한다고 쳤을때, 요리에 필요한 행위 과정만을 나열하는 것이다.

접시가 바뀌든, 요리사가 바뀌든, 레스토랑이 바뀌는 등의 상황에도 어쨌든 요리 과정은 변함 없을 것이다.

 

 

F. Repository 구현

1. Spring JPA를 사용하는 레포지토리, 그 외 커스텀해서 사용하는 레포지토리를 나누었다.

- 각각 interface를 생성하고, 그것들을 구현하는 impl 클래스를 만들어주었다.

- port 디렉토리 하위의 인터페이스는 다른 모듈(주문, 회원 기타 등등...)에서 가져다 쓰라고 객체지향의 5원칙 중 개방-폐쇄 원칙을 적용하여 설계한 것이다.

-> 이런 설계를 통해 다른 파트를 담당하는 사람들은 내부적으로 세세한 동작 방법까지 알지 못해도 간단하게 가져다 쓸 수 있게 된다.

- Spring JPA를 사용하는 레포지토리인 CategoryRepositoryImpl 클래스는 CategoryRepository를 구현하고, CategoryJpaRepository 인터페이스는 포함관계로 가지고 있는 형태로 구현하였다.

@Repository
@RequiredArgsConstructor
public class CategoryRepositoryImpl implements CategoryRepository {

    private final CategoryJpaRepository categoryJpaRepository;

    @Override
    public Category findById(Long id) {
        return categoryJpaRepository.findById(id)
                .orElseThrow(() -> new JpaObjectRetrievalFailureException(new EntityNotFoundException("카테고리가 존재하지 않습니다.")));
    }

    @Override
    public void save(Category category) {
        categoryJpaRepository.save(category);
    }

    @Override
    public void saveAll(List<Category> categories) {
        categoryJpaRepository.saveAll(categories);
    }

    @Override
    public Category findByName(String name) {
        return categoryJpaRepository.findByName(name).orElseGet(() -> Category.builder().name("EMPTY").build());
    }

    @Override
    public List<Category> findAllByParentId(Long parentId) {
        return categoryJpaRepository.findAllByParentId(parentId).orElseGet(ArrayList::new);
    }

}

- CategoryJpaRepository의 반환값을 Optional로 설정해서 NPE(Null Point Error)의 상황을 방지해주었다.

public interface CategoryJpaRepository extends JpaRepository<Category, Long> {

    Optional<Category> findByName(String name);

    Optional<Category> findById(Long categoryId);

    @Query(value = "SELECT c FROM Category c WHERE c.parentId=:parentId ")
    Optional<List<Category>> findAllByParentId(@Param("parentId") Long parentId);

}

위에서 parentId가 따로 변수로 존재하는 이유가 바로 하위 카테고리를 조회하는 JPQL을 사용하는 메서드에서

따로 변수를 선언하지 않으면 파라미터로 받을 수가 없는 문제가 발생해서 따로 변수를 선언해주었다.

왜 이렇게 해야하는 지는 모르겠다.

 

 

2. QueryDsl을 사용해서 재귀쿼리를 구현

@Repository
@RequiredArgsConstructor
public class CategoryCustomRepositoryImpl implements CategoryCustomRepository {

    private final JPAQueryFactory queryFactory;

    @Override
    public List<Category> findAllOrderByParentIdAscNullsFirstCategoryIdAsc() {
        QCategory c1 = new QCategory("c1");
        QCategory c2 = new QCategory("c2");


        List<Category> result = queryFactory
                .select(Projections.fields(Category.class,
                        c1.id,
                        c2.as("parent"),
                        c1.level,
                        c1.name
                        )
                )
                .from(c1)
                .leftJoin(c2).on(c2.eq(c1.parent),c1.id.ne(c1.parent.id))
                .orderBy(c2.id.asc(),c1.id.asc())
                .fetch();

        if (result == null){
            return new ArrayList<>();
        }

        return result;
    }

}

• 장점1 : 문자가 아닌 코드를 작성하므로 컴파일 시점에 문법 오류를 쉽게 확인 가능하다
• 장점2 : IDE의 도움을 받아서 코드 작성시 자동 완성이 되는 등의 편리함이 있다.
• 장점3 : 동적인 쿼리 작성이 편하다.

바로 Category 객체 리스트로 반환하도록 구현하였고, 결과가 null일 때는 빈 배열을 반환함으로써 NPE를 방지했다.

 

G. 구현 마무리 (자체 helper 구현)

public List<CategoryDto> getTotalCategories() {
    List<Category> categoryList = categoryCustomRepository.findAllOrderByParentIdAscNullsFirstCategoryIdAsc();
    return CategoryDto.toDtoList(categoryList);
}

다시 서비스 코드를 보면, Dto객체의 toDtoList 메서드를 통해 Category 객체 리스트가 변환되어 반환되고 있다.

public static List<CategoryDto> toDtoList(List<Category> categories){

    NestedConvertHelper helper = NestedConvertHelper.newInstance(
            categories,
            c -> CategoryDto.of(c),
            c -> c.getParent(),
            c -> c.getId(),
            d -> d.getChildCategories()
    );
    return helper.convert();
}

이 코드를 Dto 클래스에 추가 해주었다.

1. 자체 helper

• 현재 남아있는 숙제가 Category 객체 리스트 <-> CategoryDto 객체 리스트의 형변환이다.
• QueryDsl을 통해 반환된 Category객체 리스트는 연관관계가 다 맵핑되어있는 상태이다.
• 연관관계가 맵핑된 상태 그대로 CategoryDto객체의 childCategories에 넣어주는 작업이 필요하다.

public class NestedConvertHelper<K, E, D> {

    private List<E> entities;
    private Function<E, D> toDto;
    private Function<E, E> getParent;
    private Function<E, K> getKey;    // id 값
    private Function<D, List<D>> getChildren;


    public static <K, E, D> NestedConvertHelper newInstance(List<E> entities, Function<E, D> toDto, Function<E, E> getParent, Function<E, K> getKey, Function<D, List<D>> getChildren) {
        return new NestedConvertHelper<K, E, D>(entities, toDto, getParent, getKey, getChildren);
    }

    private NestedConvertHelper(List<E> entities, Function<E, D> toDto, Function<E, E> getParent, Function<E, K> getKey, Function<D, List<D>> getChildren) {
        this.entities = entities;
        this.toDto = toDto;
        this.getParent = getParent;
        this.getKey = getKey;
        this.getChildren = getChildren;
    }

    public List<D> convert() {
        try {
            return convertInternal();
        } catch (NullPointerException e) {
            throw new CannotConvertNestedStructureException(e.getMessage());
        }
    }

    private List<D> convertInternal() {
        Map<K, D> map = new HashMap<>();
        List<D> roots = new ArrayList<>();

        for (E e : entities) {
            // entity Dto 변환
            D dto = toDto(e);
            map.put(getKey(e), dto);
            if (hasParent(e)) {
                E parent = getParent(e);
                K parentKey = getKey(parent);
                D parentDto = map.get(parentKey);
                // 부모 DTO의 children 값에 지금 dto 추가해줌
                getChildren(parentDto).add(dto);
            } else {
                // 부모가 없으면 root 엔티티
                roots.add(dto);
            }
        }
        return roots;
    }

    private boolean hasParent(E e) {
        // 부모가 null이 아니거나 null이 아닌 조건 중에 부모 id랑 자신의 id가 다르면 부모가 있는거임
        AtomicBoolean b = new AtomicBoolean(false);
        if (getParent(e) != null && (getKey(getParent(e)) != getKey(e))) b.set(true);
        else {
            b.set(false);
        }
        return b.get();
    }

    private E getParent(E e) {
        return getParent.apply(e);
    }

    private D toDto(E e) {
        return toDto.apply(e);
    }

    private K getKey(E e) {
        return getKey.apply(e);
    }

    private List<D> getChildren(D d) {
        return getChildren.apply(d);
    }
}

쉽게 말해, 계층형 구조로 바꿔서 반환해주는 helper이다.

따로 클래스를 빼두어 재사용성을 높이고, 유지보수의 편의성을 높였다.

 

3. 특정 카테고리의 하위 카테고리 목록 조회 API

-> 부모 카테고리 id하나를 가지고 하위 카테고리를 조회하는 API는 요약 설명으로 마무리 하겠다.

1. 파라미터로 부모 카테고리 id를 받아서 해당 아이디의 레벨 정보를 받아온다

2. 3레벨이라면 그냥 Dto로 변환해서 반환한다.

3. 3레벨이 아니라면 JPA 레포지토리를 활용하여 findAllByParentId로 조회해서 DtoList로 변환하여 반환한다.