[Spring & Springboot] Generic을 이용하여 모든 Request, Response에 Header와 CRUD 인터페이스를 구성해보자.

이 시리즈는 Spring에서 Generic을 이용하여 CRUD 인터페이스를 구성해보자.와 이어지는 글 입니다.

1. Generic(제너릭)을 핵심만 이해해보자.
2. Spring에서 Generic을 이용하여 CRUD 인터페이스를 구성해보자.

이 글은 실전에 관한 글이고 제너릭에 대한 이론이 부족하신 분들은 1번 링크를 통해 충분히 숙지하고 오시는 것을 권장합니다.

---

제네릭을 실전에서 사용해보자.

지난 시간에 배운 제네릭에 이어서 이제 실전에서 사용해보기 위해 환경 구성을 해보자.

Jpa + Springboot + Mysql 연동에 대해서는

우리는 모든 Http 통신에 Header라는 공통 부분이 들어가야 하는 것을 알고 있다.

원래라면 request, response 에 setHeader라는 메서드를 통해 헤더를 관리하겠지만 제네릭의 이해를 위해 직접 Header라는 클래스를 만들고 모든 요청과 응답에 Header를 붙혀서 작성해보자.

이러한 모델을 통신하려고 하는데 모든 통신이 이루어질 때 마다 Header에 다음과 같은 정보가 필요하다고 요구한다.

• transaction_time (통신 시각)
• status (통신 상태 코드 OK, ERROR)
• description (세부 내용:: 통신이 발생한 서버 주체)
• data (데이터)

그럼 모든 통신을 Header라는 클래스에 담아서 Request와 Response를 수행할 것인데 다음과 같은 형식의 JSON으로 통신이 이루어질 것이다.

그리고 모든 모델마다 CRUD를 수행한다고 가정하고 공통 부분을 묶어주는 CrudInterface 인터페이스를 만들어서 모델에 관한 Controller에서 통신을 연결해보자.

Overview

원래는 3개의 엔티티 클래스를 모두 작성해야 맞는 것 이지만 같은 코드의 반복인 작업으로 하나의 User와 관련된 작업으로 대체하겠습니다. 단지 이해를 돕기 위해 불필요한 중복을 최소화하는 과정이지 클래스를 덜 작성한다고 해서 포스팅의 질이 낮아지는 것은 아니라고 판단되었으며 모든 소스코드가 필요하신 분들은 댓글을 남겨주세요 :)

일단 어떤 패키지가 존재하는지 먼제 확인해보자.

1. model
2. controller
3. service
4. ifs

패키지

model
모델 패키지에는 Entity, Repository등과 같은 DB에 매핑되거나 통신의 Body 부분에 대응하는 객체가 담길 패키지이다.
Entity, Repository뿐만 아니라 우리가 만들게 될 네트워크에 Header 객체 또한 model 패키지에 존재하게 된다.

controller
controller 패키지는 잘 알디싶이 controller가 위치하게 될 패키지이다.

service
service 패키지 또한 알다싶이 controller에서 사용하게 될 service logic이 모여있는 패키지라고 생각해두자.

ifs
이 부분과 model 패키지가 이번 포스팅에 핵심인 녀석들이다.
우리는 모든 서비스 로직에서 공통되는 부분, 즉 CRUD를 하나의 인터페이스에서 상속받을 수 있게 강제화 할 것이다.
그런 의미에서 ifs 패키지는 CrudInterface라는 인터페이스가 존재할 인터페이스 패키지 이다.

클래스

클래스를 패키지의 하위에 어떤 클래스가 있을지 먼저 생각해보자.

가장 쉬운 controller, service는 단지 저 두 로직의 클래스만 있을 것이니 model을 중점적으로 이야기 해보자.

model

• entity : 실제 DB와 매핑될 JPA 엔티티 클래스
• request : Header에 Data(Entity)가 결합되어 실제 통신에 필요한 정보를 담고 있는 Request 클래스
• response : Request가 서비스 로직에 의해 가공된 Data를 Header와 결합된 Response 클래스
• header : 요청에 필요한 Header 정보를 담고 있는 클래스

이렇게 4가지가 위치할 것이다.

JPA 구성

먼저 간단한 통신 테스트로 JPA를 구성해보자.

User

package com.example.demo.model;

import lombok.Data;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String username;

    private String password;
}

UserRepository

package com.example.demo.repository;

import com.example.demo.model.User;
import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {
}

이제 간단한 JPA를 생성했고, controller, service에서 CRUD를 사용할 수 있도록 해보자

네트워크 관련 객체 준비

UserRequest

package com.example.demo.model.network;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class UserRequest {
    private String account;
    private String password;
    private String name;
}

UserResponse

package com.example.demo.model.network;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@AllArgsConstructor
@NoArgsConstructor
@Builder
public class UserResponse {
    private String account;
    private String password;
    private String name;
}

이렇게 두 개의 Request, Response 클래스를 각각 생성해준다.

그리고 대망의 Header 클래스를 생성할 차례

여기서 제너릭이 어떻게 쓰이냐?

바로 공통된 부분의 Header에 사용하면 제너릭을 좀 더 우아하게 사용할 수 있을 것 같다.

Header 클래스

Header 클래스는

• transaction_time (통신 시각)
• status (통신 상태 코드 OK, ERROR)
• description (세부 내용:: 통신이 발생한 서버 주체)

과 같은 공통 정보를 갖고 있고, 매 요청과 응답마다 정보를 넘겨야 하므로 Header라는 클래스의 필드를 작성할 수 있다.

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@SuppressWarnings("unchecked")
class Header {
    private LocalDateTime transaction_time;
    private String status;
    private String description
}

여기서 첫 번째 제네릭을 사용할 수 있다.

헤더는 요청과 응답을 감싸야 하므로 Header 클래스에는 UserApiRequest, UserApiResponse 클래스의 타입만 들어온다.
이는 조금 더 확대해서 해석하자면 헤더는 어차피 요청과 응답에만 관여를 하는 데이터 객체이므로 2가지의 타입이 들어온다는 것이다.

그럼 우리는 타입 체크를 위해 제너릭이라는 선택지를 이용할 수 있다.

기존의 Header 클래스에서 타입을 붙혀서 아래와 같이 만들어보자.

package com.example.demo.model.network;

import java.time.LocalDateTime;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@SuppressWarnings("unchecked")
public class Header<T> {
    private LocalDateTime transaction_time;
    private String status;
    private String description;
}

첫 번쨰의 제너릭을 사용해서 컴파일 시점에 타입을 체크할 수 있게 했다.

이제 Header의 기능을 완벽하게 만들어보자.

여기서 말 하는 완벽하게는 모든 요청에 통신 시각, 통신 코드, 추신, 데이터를 추가해서

Header 클래스에서 Static으로 요청의 성공과 실패 여부를 OK, ERROR 메서드로 분리시켜보자.

메서드를 제네릭 메서드로 만들어주고 단순 성공 OK와 데이터가 존재하는 성공 OK(T data) 그리고 실패 ERROR() 이 세 가지의 메서드를 만들어보자.

package com.example.demo.model.network;

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;

import java.time.LocalDateTime;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@SuppressWarnings("unchecked")
public class Header<T> {
    private LocalDateTime transaction_time;
    private String status;
    private String description;

    private T data; // 제네릭 데이터

    public static <T> Header<T> OK(){
        return (Header<T>)Header.builder()
                .transaction_time(LocalDateTime.now())
                .status("OK")
                .description("From UserApi")
                .build();
    }

    public static <T> Header<T> OK(T data) {
        return (Header<T>) Header.builder()
                .transaction_time(LocalDateTime.now())
                .status("Data-OK")
                .description("From UserAPI")
                .build();
    }

    public static <T> Header<T> ERROR() {
        return (Header<T>) Header.builder()
                .transaction_time(LocalDateTime.now())
                .status("ERROR")
                .description("From UserAPI")
                .build();
    }

}

공통 부분을 하나의 Interface로

공통 부분인 CRUD를 하나의 CrudInterface로 관리하기 위해 CrudInterface 인터페이스를 생성한다.

여기서도 제네릭을 어떻게 사용하면 좋을지 생각해보자.

제네릭을 사용하면 특정 객체만 들어올 수 있게 제한할 수 있다고 했다.

그럼 어떤 데이터들이 CrudInterface를 사용할까?

정답이다.
바로 UserRequest, UserResponse, ItemRequest, ItemResponse, OrderRequest, OrderResponse가 있다.
하지만 이 요청과 응답 객체들은 서로 함께 움직여야 한다.
무슨 말이냐면 Request가 들어오면 Response로 반환하는 것이 기본 매커니즘이다.
이들 모두를 포함할 수 있는 제네릭은 바로 <Request, Response>이다. 그럼 인터페이스를 만들어보자

package com.example.demo.ifs;

public interface CrudInterface<Request, Response> {
    Response create(Request request);

    Response read(Long id);

    Response update(Request request);

    Response delete(Long id);
}

여기서 잠깐, read()와 delete()는 왜 request가 아니라 ID 일지 생각해보자.
우리는 사용자의 검색에 대한 요청을 PathVariable 형태로 받을 것이다. 그러므로 사실상 요청 데이터에는 url의 경로가 사용될 것이므로 통신 객체가 아닌 Primitive 형태이므로 Long 형태를 사용한다.

이런 식으로 CRUD 메서드마다 요청과 응답이 서로 존재하는 형태가 될 것이다.
하지만 여기서 모든 요청과 응답은 Header에 의해 감싸져야 한다고 했으므로 아래와 같이 바뀌는게 더욱 적절하다.

package com.example.demo.ifs;

import com.example.demo.model.network.Header;

public interface CrudInterface<Request, Response> {
    Header<Response> create(Header<Request> request);

    Header<Response> read(Long id);

    Header<Response> update(Header<Request> request);

    Header delete(Long id);
}

마지막 delete 메서드에는 response할 데이터가 존재하지 않기 때문에 잠시 뺴두자.

이제 모든 준비가 끝났다.

실제 서비스를 만들면서 우리가 예상했던 코드가 잘 동작하는지 확인해보자.

---

Service 구현

UserService

package com.example.demo.service;

import com.example.demo.ifs.CrudInterface;
import com.example.demo.model.network.Header;
import com.example.demo.model.network.UserRequest;
import com.example.demo.model.network.UserResponse;
import com.example.demo.repository.UserRepository;
import org.springframework.stereotype.Service;

@Service
public class UserService implements CrudInterface<UserRequest, UserResponse> {
    @Override
    public Header<UserResponse> create(Header<UserRequest> request) {
        return null;
    }

    @Override
    public Header<UserResponse> read(Header<UserRequest> request) {
        return null;
    }

    @Override
    public Header<UserResponse> update(Header<UserRequest> request) {
        return null;
    }

    @Override
    public Header delete(Header<UserRequest> request) {
        return null;
    }
}

우리가 만든 서비스 코드에 CrudInterface 인터페이스를 구현해준다면 아마 위와 같은 상태의 코드가 나타나게 된다.

이제 소스코드를 구현하는 과정만 남았다.

create 메서드 작성

create 메서드 작성의 순서는 다음과 같다.

1. request에서 Data 부분 가져오기
2. Data부분을 User 객체와 매핑
3. Jpa 레포지토리 save
4. response 데이터로 바꾸기
5. Header에 Data 부분을 response로 지정

@Override
public Header<UserResponse> create(Header<UserRequest> request) {
    UserRequest userRequest = request.getData();

    User user = User.builder()
            .username(userRequest.getUsername())
            .password(userRequest.getPassword())
            .name((userRequest.getName()))
            .build();

    User newUser = userRepository.save(user);

    UserResponse userResponse = UserResponse.builder()
            .username(newUser.getUsername())
            .password(newUser.getPassword())
            .name(newUser.getName())
            .build();

    return Header.OK(userResponse);
}

read 메서드 작성

read 메서드의 작성 순서는 다음과 같다.

1. Path Variable의 값을 토대로 repository에 findById 실행
2. 실행 결과를 Header가 포함된 response로 변경

read 메서드는 큰 힘이 필요하지 않지만 약간 까다로울 수 있는게, 람다에 익숙하지 않은 사람들이 이해하기 힘든 코드가 나온다.
이번시간은 람다에 대해 이야기하는게 아니므로 넘어가겠지만 블로그의 람다 게시글을 통해 학습해보는 것도 좋은 경험이 될 것이다.