Skip to content

1. Spring boot JPA의 구조, 작동방식

Jump to bottom
chodakk edited this page Mar 3, 2022 · 1 revision

Spring boot+JPA를 프론트 => 백엔드 순으로 나열한 구조

  1. Controller
  2. Service
  3. Repository
  4. DB(우리에겐 MySQL)

1. Controller

  • 프론트에서 Request가 들어올 때 그 Request를 알맞게 처리하는 클래스라고 생각하면 됨.
  • 큰 로직을 갖고 있기 보다는 네트워크 라우터가 패킷을 최적의 경로로 안내하는 것처럼 Request에 대해 넌 이리로! 넌 저리로! 지시하는 역할.
  • 프론트에서 Response를 원한다면 결과값을 Controller에서 Rest로 내보내는 역할도 함.
  • 그럼 Controller에서 어떻게 Request를 처리해요? 한다면... 그냥 Request를 가공해서 DTO에 저장하고, DTO를 Service로 던져서 갖고 논다고 생각하면 됨.

1-1. DTO

  • DTO를 검색하면 계층 간 통신을 위한 데이터의 뭐시기저시기... 하는데 사실 난 뭔 개소린지 와닿지 않아서 친구한테 질문한거임ㅎ
  • 보통은 프론트에서 Request가 들어오면 이 Request에 대한 data class라고 생각하면 됨. 예를 들면 다음과 같음.

    프론트 : 백엔드야 회원가입 들어왔는데 이거 DB에 저장 좀 해줘... 정보는 조다은, 24살, 99년생 1월 20일이거 아이디는 chodakk, 비밀번호는 sogongsogong임.
    백엔드 : ㅇㅋ. 들어오는 데이터는 즉 name(String), age(int), bday(string), id(string), passwd(string)이네? 그럼 앞으로 회원가입에 대한 데이터는 쭉 이렇게 올테니까 이에 대한 data class를 만들어놓자!
    data class LoginDTO(var name:String, var age:Int, var bday:String, var id:String, var passwd:String)

  • 반대로 우리가 Response할 때에도 DTO에 들어있는 data값을 내보내기도 함. 만약 Request와 Response가 상이하게 다르면 DTO를 분리할수도.

    프론트 : 백엔드야 우리가 치킨 쿠폰 줄테니까. 너네는 ssd 주면 돼.
    백엔드 : 그럼 Request DTO는 치킨 쿠폰을 담을 DTO, Response DTO는 ssd를 담을 DTO를 만들면 되겠네!

  • 보통은 DTO와 DB구조(Entity의 구조)를 비슷하게 하는데, DTO는 외래키(FK)에 대한 정보를 담지 않는다는 점.
    그럼 외래키는 어떻게 받고 처리해요? -> 받는건 그냥 프론트에서 줘야하고, 처리하는 건 Service에 가서 함. 2번에서 서술.

2. Service

  • Controller가 시키는 일을 하는 클래스임. 그냥 Controller가 상사, Service가 사원이라고 생각하자.
  • 주로 로직을 이쪽에서 처리하는 편.
  • 사실 프론트에서 Request가 들어오면 이를 가공해서 DTO에 저장하는 작업을 Controller가 아닌 Service에서도 할 수 있긴함.
    근데 안그래도 사원(Service)이 할 일이 많은 것 같은데 상사(Controller)가 적절히 좀 처리해서 넘기는게 유지보수에 더 낫지 않을까 싶음.
  • 또 DB의 데이터를 CRUD 및 비교하는 작업을 Service에서 수행함.
    Service가 CRUD한다는 뜻이 아니라 DTO와 DB의 중간 지점이 Service이기 때문에 이 곳에서 작업을 수행한다는 뜻.
    서울사람과 부산사람이 당근거래 하려고 대전에서 만나는 것이지, 대전이 당근거래를 하진 않는 것처럼... 이렇게 이해하면 될듯.
  • 위에서 언급한 외래키는 어떻게 처리합니까? 자세히 좀 알려주세요!

    만약 게시글 저장 Request가 들어왔는데 사용자의 이름이 Response 돼야 하는 로직이 있다고 가정하자.
    Request로는 게시글의 세부 정보와 사용자의 id(db에선 외래키, DTO에선 그냥 Integer)가 들어오게 되고, 우리는 외래키를 통해 사용자의 이름을 알아내야 Response 하겠지?
    그럼 그냥 우리는 Service에서 DTO의 사용자id 값을 가지고 사용자 정보DB에서 사용자의 이름을 select(findByuserid)한 뒤 Controller에게 값을 주면 됨.

  • 그럼 db를 어떻게 CRUD 하나요?

3. Repository

  • 이 곳에서 처리합니다^^
  • 난 사실 DAO = Repository인 줄 알았는데, 엄밀히 말하면 둘이 좀 다른 개념이라 함.
    하지만 JpaRepository에선 혼용해서 쓰기도 하고, 둘의 차이가 모호해서 지금은 알지 않아도 되는듯. (알고 싶으면 : https://bbbicb.tistory.com/44)
  • Entity와 연결해서 CRUD를 수행하는 역할임. 즉 DB와 가까이 붙어서 데이터를 다루는 곳!
  • 만약 Repository를 통해 DB에 저장한다고 하면 그냥 DTO를 Repository에 넣어서 save하면 되나요?

    아닙니다^^. Repository의 save는 Entity 객체로 받기 때문에 DTO 값에서 Entity객체를 생성하고, 이 Entity를 Repository save에 넣으면 됩니다^^~.

  • 그럼 외래키는 어떻게 저장해야 되죠?

    게시판db 구성이 게시글id(기본키:PK), 사용자id(사용자 정보DB에서 온 외래키), 내용으로 구성되어 있을 때...
    프론트에선 사용자id, 내용만 올 것이고 (기본키인 게시글id는 안넣어줘도 ㄱㅊ음) DTO에는 사용자id:Int, 내용:String으로 저장되겠죠?
    그럼 DTO를 Entity로 변환하기 위해선 사용자id가 사용자 정보Entity 객체여야하는데...
    일단 Repository에서 사용자id로 사용자정보db를 조회하고 사용자 정보 Entity 객체에 저장한 뒤 이를 내용과 함께 게시글 Entity로 저장한다!!!!
    ...는 이렇게 하는건지 잘 몰라서 다시 물어봄.
    -> 물어보니까 맞다고 함. 어차피 게시글db에 저장하기 위해서 사용자id가 유효한지 검증해야하는데 그때 불러오면 된대.

3-1. Entity

  • DB 테이블과 직접적인 연관이 있는 곳^~^
  • DB 테이블, Column 설정을 담당하고 있는 부분입니다.^^~ 끗.
Clone this wiki locally