인프런 커뮤니티 질문&답변

Q) 컨트롤러에서 form에서 보낸 요청을 받고 로직을 처리하는데, 이 때 시기적절하게 사용될게 Repository입니다.

A) Repository의 역할을 간단히 설명드리면, 순수 JPA에서 전체 조회를 하려면 다음과 같이 구현해야 했습니다.

하지만 스프링데이터JPA를 사용하면

간단 조회, 삭제 등은 JpaRepository를 사용하면 코드(쿼리) 구현 없이 사용할 수 있습니다. 

public interface MemberRepository extends<JpaRepository<Member,Long> {}만 작성하면

위의 메서드들은 바로 사용할 수 있는것이지요. 이렇게 편리한 기술부터 강의 처음부터 다루지 않으신 이유는 내부적으로 어떻게 돌고 있는지 기반 기술을 설명해야 스프링데이터JPA를 잘 다룰 수 있기 때문입니다.

DB와 상호작용을 하려면 쿼리(SQL)가 발생해야 하는데 Repository는 이 부분을 담당합니다.

　

Q) VIEW 혹은 프론트분들(?)의 API에 (?) 보내준다고 생각했습니다

A) Controller에서 직접적인 상호작용이 일어나며 핵심 로직을 호출합니다.(View 혹은 API). Service에서는 핵심로직이 발생(구현)하며 Service에서 Repository를 호출합니다.

사용자(웹 혹은 API호출) -> Controller -> Service -> Repository -> DB 이 구조입니다.

DB에 있는 데이터를 사용자한테 보내주려면 반대로 전달이 되겠죠?

DB에 있는 데이터를 Repository에서 조회하고 Service에서 Repository를 호출하고 Controller는 해당 Service를 호출하고 호출한 데이터를 최종적으로 사용자한테 보내주는것이요.

※ 간단한 로직의 경우 Service없이 Controller에서 바로 Repository를 호출하기도 합니다.

　

Q) 그리고 JpaRepository를 상속받았을 때 어떻게 해야할지 잘 모르겠는데요 ㅠㅠ 현재 활용편만 보고 어떤 엄청난 기술(?)인지 파악해보려고 노력했습니다. 기본편을 다시 듣고 활용편을 다시 거쳐 활용2편에서 공부를 더 해봐야할것같습니다 ! (근데 지금 프로젝트 진행중이라 시간에 제약이 있네요 ㅠㅠ)

A) 일반적인 학습을 진행하시는 분이라면 야생형 스타일을 권해드리는데요(활용1편->기본편-> 활용1편복습 -> 활용2편->SPringDATAJPA->QueryDSL) 프로젝트를 바로 진행하시고 계시다고 하시고 시간 제약도 있으시니 SpringDATAJPA 강좌를 빠르게 수강하시는게 좋을 수도 있다는 생각이 듭니다. 그렇게 생각한 이유는 SpringDATAJPA 강의에서는 기본편, 활용편에서 진행되었던 순수 JPA 방식을 스프링데이터JPA로 바꾸는 과정을 보여주시는데 이 부분이 지금 australialove19

님한테 내부의 아키텍처보다는 당장 필요한 부분일수도 있겠다라는 생각이 드네요.

하지만 추후 다시 기본편으로 돌아와 학습하시는 것을 꼭하셨으면 좋겠습니다. 

Q) interface에 JpaRepository를 상속 받아서 하는 것을 JPA 기본편, 활용편 두 강의 모두 어디서 부터(기본편 몇 강 부터 ~, 활용편 몇 강 부터 ~) 시작하는지 알려주시면 감사하겠습니다 !!

A) 기본편, 활용1,2편에서 진행되지 않는 부분입니다. 스프링데이터JPA 강의에서 진행됩니다.

혹은 공식문서를 참고하셔도 좋습니다.

　

Q) 해당 강의에서는 Member 클래스를 만들어서 getter setter로  데이터를 참조한것 같다는 느낌을 받았습니다!

하지만 JPA를 사용하게 되면 DB에 데이터를 저장하고 사용하게 될텐데, 따로 클래스를 만들어 줘야하는건지, 아니면 Entity를 해당 강의 Member 클래스처럼 참조해서 DB에 데이터를 저장하는 구조인지 궁금합니다 !

"제 생각부터 말씀드리면 "JPA는 DB에 회원(Member) 테이블이 있을 때 이 Member테이블에 해당하는 정보를 JPA에서 Member class(Entity)로 구현하여 매핑시키는 기술" 이라고 생각하는데"에 의하면 제 생각이 맞고 말씀해주신 것 같은데 제가 잘 이해한게 맞을까요? ㅎㅎ

A) 생각을 공유해주셔서 어느 부분에서 헷갈리시는지 알 것 같습니다. 

australialove19님이 생각하는 Repository의 역할을 알려주실 수 있을까요?

제 답변과 australialove19님의 생각에서 Repository의 개념이 빠져있는데 이 부분과 연관지어 생각하시면 이해에 도움이 될 것 같아서요.

우선 제 생각은 Member 라는 클래스를 MemberRepository에 저장하고 MemberRepository에 필요에 따라 조회(검색)하고 업데이트나 삭제 등을 하며 해당 Repository를 통해 실제 DB에 저장까지 이뤄진다고 생각하는데요. 

가령 Controller는 Web 브라우저(클라이언트)와의 상호작용을, Repository는 DB와의 상호작용을 한다고 생각하며,

화면단의 Form 데이터를 Controller에서 커맨드 객체로 받아오는 것 , Member Entity를 Repository를 통해 DB에 관리하는 것과 같은 행위가 이뤄진다고 생각합니다.

australialove19 님은 어떻게 생각하시는지 공유해주시면 감사하겠습니다.

정말 생각을 공유하고 소통하는 느낌이라 너무 좋네요 :) 감사합니다 !

일단 제가 생각했던 Repository는 사용자가 이름, 비밀번호를 입력했다고 했을 때,

컨트롤러에서 form에서 보낸 요청을 받고 로직을 처리하는데, 이 때 시기적절하게 사용될게 Repository입니다.

DB에서 저장된 내용을 불러오거나 저장시킬 때 사용되고, 원하는 결과값을 DB에서 찾아서 리턴시켜서 VIEW 혹은 프론트분들(?)의 API에 (?) 보내준다고 생각했습니다. (사실 리액트 프론트분들이랑 프로젝트를 하고 있는데 API 소통방식을 잘 모르겠습니다 ㅠㅠ)

그리고 JpaRepository를 상속받았을 때 어떻게 해야할지 잘 모르겠는데요 ㅠㅠ 현재 활용편만 보고 어떤 엄청난 기술(?)인지 파악해보려고 노력했습니다. 기본편을 다시 듣고 활용편을 다시 거쳐 활용2편에서 공부를 더 해봐야할것같습니다 ! (근데 지금 프로젝트 진행중이라 시간에 제약이 있네요 ㅠㅠ)

컨트롤러에서 로직을 처리할 때, xxxRepository 인터페이스에서 로직을 처리하고 다시 컨트롤러에 반환한다고 생각했습니다 !

조금 더 솔직하게 말하자면, 이 부분에 대해서 깊게 생각해보지 않았었는데 방금 질문으로 생각해보고 정리해서 말해보았습니다! 혹시 틀린 부분이나 조언해주실 부분이 있다면 가감없이 해주시면 감사하겠습니다 !!

interface에 JpaRepository를 상속 받아서 하는 것을 JPA 기본편, 활용편 두 강의 모두 어디서 부터(기본편 몇 강 부터 ~, 활용편 몇 강 부터 ~) 시작하는지 알려주시면 감사하겠습니다 !!

아래에 Entity 설계 첨부합니다 !

해당 강의에서는 Member 클래스를 만들어서 getter setter로  데이터를 참조한것 같다는 느낌을 받았습니다!

하지만 JPA를 사용하게 되면 DB에 데이터를 저장하고 사용하게 될텐데, 따로 클래스를 만들어 줘야하는건지, 아니면 Entity를 해당 강의 Member 클래스처럼 참조해서 DB에 데이터를 저장하는 구조인지 궁금합니다 !

"제 생각부터 말씀드리면 "JPA는 DB에 회원(Member) 테이블이 있을 때 이 Member테이블에 해당하는 정보를 JPA에서 Member class(Entity)로 구현하여 매핑시키는 기술" 이라고 생각하는데"에 의하면 제 생각이 맞고 말씀해주신 것 같은데 제가 잘 이해한게 맞을까요? ㅎㅎ

답변 감사합니다 !

안녕하세요. australialove19님, 공식 서포터즈 OMG입니다.

Q1) 지금 API 통신은 어떻게 되는지 감이 잘 안오네요 ㅠㅠ

리액트 개발자 분들과 프로젝트를 진행중인데, 소통은 어떻게 하는지 레퍼런스나 키워드 알려주실 수 있나요..?

A) JPA를 사용한 API 개발은 활용 2편에서 김영한 지식공유자님이 자세히 알려주십니다.

프론트엔드 개발자와의 소통은 API 문서로 진행되며 다음과 같은 키워드로 검색하시면 많은 자료들이 나옵니다.

　

Q2) 강의에서는 member 클래스와 repository 클래스를 만듭니다.

여기서는 JPA를 사용하지 않아서 respository를 만든 것 같은데요,

JPA를 사용하면 interface에 JpaRepository를 만듦으로서 이 해당 클래스를 대체했다고 봐도 무관할까요??

A2) 맞습니다. JPARepository의 메서드를 모방한 repository를 설계하여 설명해주십니다. 말씀하신 형태의 강의진행은 JPA 기본편, 활용편에서도 동일하게 진행되며 스프링데이터JPA 강의에서 스프링 데이터JPA가 제공해주는 메서드로의 변환된 과정을 설명해주십니다.

　

Q3) JPA를 사용하면 interface에 JpaRepository를 만듦으로서 이 해당 클래스를 대체했다고 봐도 무관할까요??

그래도 Member 클래스와 같은 클래스는 기본적으로 만들어 줘야 하는건지 모르겠습니다 ㅠㅠ (Entity 설계는 끝난 상태입니다 ! Entity설계한것이 Member 클래스의역할을 하는건가요??)

A3) 네 정확히는 스프링데이터JPA가 제공하는 JpaRepository를 interface로 상속받아 사용하는 것으로 보시면 됩니다.

Entity 설계는 끝나셨다고 하셨는데 Entity 설계를 어떻게 하셨는지 예시를 들어주시면 보충설명 드리겠습니다. 

"Member 클래스와 같은 클래스는 기본적으로 만들어 줘야 하는건지 모르겠습니다 ㅠㅠ" 이 부분에 대해서도 구체적으로 왜 그러한 생각을 하시는지 설명해주시면 감사하겠습니다.

제 생각부터 말씀드리면 "JPA는 DB에 회원(Member) 테이블이 있을 때 이 Member테이블에 해당하는 정보를 JPA에서 Member class(Entity)로 구현하여 매핑시키는 기술" 이라고 생각하는데 australialove19님의 생각을 공유해주세요.

감사합니다.