인프런 커뮤니티 질문&답변
작성한 질문수
안녕하세요! 생성자와 필드의 타입에 관련하여 질문있습니다
해결된 질문
작성
·
329
답변 2
1
안녕하세요!! alsgudtkwjs님!! 질문 주셔서 감사드립니다~~! ☺️
하나하나 설명 드려보겠습니다!!
[1. JPA에서 protected 기본 생성자의 의미]
저희가 기본 생성자를 추가로 만들어 준 이유는, JPA가 정상 동작하기 위해서 입니다!!
protected도 괜찮고~ public도 괜찮은데요! JPA의 경우, 내부적으로 "리플렉션"이라는 자바의 기술을 활용하고 이 기술을 활용할 때 기본 생성자를 사용하고 있어요!
따라서 JPA가 온전히 동작하려면 기본 생성자가 필요하게 됩니다.
[2. id는 Long 타입인데 userId는 long 타입인 이유 + 3. id = null;을 한 이유]
Long과 long의 차이는 null 이 들어갈 수 있는지~ 없는지~ 입니다!
(관련해서 자바의 boxing과 unboxing에 대해 찾아 보셔도 좋을 것 같아요! 👍)
private Long id = null; 처럼 id라는 필드에 null 이 들어갈 수 있는 Long 타입을 설정하고, 초기값으로 null 을 넣어준 이유는 우리가 만들어준 데이터 (UserLoanHistory) 가 DB에 저장된 데이터인지 저장되지 않은 데이터인지 구분하기 위해서입니다!
만약 id가 여전히 null 값을 갖고 있다면, 아직 DB에 저장되지 않은 데이터이고 id에 어떤 숫자가 들어 있다면 DB에 저장된 데이터라고 생각할 수 있죠.
반대로 userId 의 경우 누군가가 책을 빌렸다면 해당 유저의 id가 무조건 숫자로 들어 있기 때문에 굳이 null이 들어갈 수 있는 Long 타입을 설정하지 않아도 괜찮습니다. 가능한 null이 들어갈 여지를 줄여주면 그만큼 버그가 작성할 확률도 줄어들게 되죠.
필드의 타입 하나에도 의도가 들어 있었는데 관찰력이 좋으시네요!! ㅎㅎㅎ
[4. DB 테이블 자동 생성]
이는 우리가 application.yml 에 설정해준 ddl-auto 옵션에 따라 달라집니다!
만약 ddl-auto 옵션에 create 혹은 create-drop 을 적용하면 자동 생성될 수 있고, none 을 적용하면 JPA 객체 만으로 테이블이 자동 생성되지는 않습니다.
개인 컴퓨터에서 개발을 할 때는 create 또는 create-drop 을 사용하기도 하지만, 다수가 접근하는 개발/운영 DB에서는 none 혹은 validate 가 권장됩니다.
궁금증이 해결되셨으면 좋겠네요~ 또 궁금증이 생기시면 편하게 말씀해주세요!
감사합니다!! 🙏
0
추가로 제가 프론트와 협업을 하고 있는데, 프론트에게 api 명세서를 넘겨주면 만약 로그인 api가 POST /api/signin 이라고 하면 로컬에서는 (POST) http://localhost:8080/api/signin 으로 postman으로 테스트를 할텐데, 프론트쪽에서 api를 통해 데이터를 받아올 때 저희가 배포하지 않고 로컬에서만 서버를 돌렸다면
프론트는 데이터를 받지 못하는건가요?
localhost:8080 이 부분을 도메인을 구입해 서버를 동작시켜야 실제로 프론트쪽에서 api로 데이터를 요청해 받을 수 있는건가요??
저희가 배포하지 않고 로컬에서만 서버를 돌렸다면 프론트는 데이터를 받지 못하는건가요?
네네 맞습니다!! 질문자님 컴퓨터에 서버가 있고, 프론트 개발 역시 질문자님 컴퓨터에서 이루어지는 것이 아니라면 "배포"를 통해 프론트가 배포된 서버에 접근할 수 있도록 해주어야 합니다. 그렇지 않으면 프론트에서는 서버의 API를 활용하기 어려워요!! 방법이 아예 없는 것은 아니고 ngrok 같은 툴을 쓸 수 있긴 하지만, 일반적이지는 않습니다.
localhost:8080 이 부분을 도메인을 구입해 서버를 동작시켜야 실제로 프론트쪽에서 api로 데이터를 요청해 받을 수 있는건가요??
개발 단계에서는 도메인은 꼭 구매할 필요가 없고, IP로 바로 접근할 수도 있습니다! 🙂
다만, 보통은 프론트 역시 배포가 필요하니 도메인을 하나 구입해서, 프론트와 백이 각각 나눠 갖습니다. 예를 들어 example.com을 샀다면, 서버가 api-dev.example.com을 사용하고 프론트가 app.example.com을 사용하는 느낌이죠! 이러한 서브도메인은 계속 만들 수 있습니다.
위의 댓글 답변도 잘 읽어보았습니다. 항상 쉽게 이해할 수 있도록 설명해주려 하심에 감사드립니다! 덕분에 코딩이 조금 재밌어지려고 하네요