블로그 만들기-(2)

Claudia Hong·2021년 11월 16일
0

Project

목록 보기
20/26

1. yml

1) yml 파일을 스프링부트 설정에 사용하는 이유?
XML 보다는 JSON이 경량이고 JSON 보다는 Yaml이 괄호가 없기 때문에 경량이다. 따라서, 더 경량인 yml을 스프링부트 설정에 사용한다.
※ yml은 하위 구분할 때 2번 띄워서 구분한다.

2) yml 설정

  • root-context.xml : 데이터베이스 설정함 객체가 한번만 있으면 되는 싱글톤인 것들을 설정

  • servlet-context.xml : 지속적으로 유해서 만들어서 사용해야 하는 것들 설정

스프링에서는 application.yml에 모든 설정들을 해주면 된다. >> 프로젝트에 진입하기 직전에 yml을 한번 읽고 시작한다.

(1) yml 내용 살펴보기

내 포트 안에 컨텍스트를 설정한다.
context-path : 내 프로젝트에 들어가기 위한 진입점

데이터베이스 설정

@Controller : 데이터를 리턴하는게 아니라 파일을 리턴/페이지로 갈때
파일 리턴 기본 경로 : src/main /resources/static (정적파일 경로 >> 브라우저가 인식할 수 있는 파일/JSP는 동적인 파일)
@RestController : 파일을 리턴한다. String을 리턴할 때, 리턴의 문자열 자체를 리턴한다./응답만 해줄 수 있는/데이터만 리턴

스프링부트는 JSP파일 지원하지 않기 때문에 JSP템플릿엔진을 의존성 설정을 해주고(JSP동작), 기본경로를 yml에 설정해야 한다.(JSP인식)

컴파일이 돼서 온다.(JSP파일을 html 형태로 브라우저가 인식하게 해줌)

2. 테이블 만들기

model 패키지에 테이블로 만들 클래스들을 생성.

1) User

@Entity : User 클래스가 MySQL에 테이블이 생성이 되게 함
@Id : id가 PK임을 알려주기 위해 어노테이션

@GeneratedValue : 넘버링전략. >> 프로젝트에서 연결된 DB의 넘버링 전략을 따라간다.(IDENTITY)

28줄 : false >> JPA가 사용하는 기본 넘버링 전략을 따라가지 않겠다.

즉, JPA전략을 따르지 않고 DB의 넘버링 전략을 따르겠다고 설정한 것.

@CreationTimestamp : 시간이 자동으로 입력됨.

role은 Enum을 쓰는게 좋다 >> 어떤 데이터의 도메인을 만들 수 있으므로. (오타로 권한을 잘못 적는 경우를 방지 ※ 도메인 >> 어떤 범위가 정해진다는 의미.)

@CoulumnDefault(" ' ' ") :안에 홑따옴표를 넣어야 함.(문자임을 알려주기 위해)

프로젝트를 실행하면 테이블이 만들어지게 된다.(콘솔창에 만들어진게 나옴) >> 25줄 create 29줄 true
※ 보기 좋게 정렬돼서 보이는 이유 : 31줄

ORM >> JAVA(다른언어) Object를 Table로 매핑해주는 기술이다.

2) Board

JPA에서는 FK로 user 정보를 찾는게 아니라 User 오브젝트를 바로 가지고 온다.

데이터베이스는 오브젝트를 저장할 수 없다 >> FK 사용
자바는 오브젝트를 저장할 수 있다 >> DB와 자바의 충돌이 일어남 >> FK값을 저장한다. BUT JPA를 사용하면 오브젝트를 그대로 저장이 가능함.

DB와 연결하기 위해서 @JoinColumn으로 저장될 필드값을 지정하고, @ManyToOne 어노테이션으로 조인될 칼럼과의 연관관계를 지정한다.
(한명의 유저는 여러개의 게시글을 쓸 수 있다.) >> 자동으로 FK 생성됨.

ManyToOne이므로 user 정보는 1개이기 때문에 패치전략이 Eager (가져올 정보가 1건 밖에 없으므로 바로 가져와서 조인한다.)

※ 블로그 화면을 생각해보기

유저네임 >> 유저테이블
제목, 내용 >> 보드테이블
댓글 (댓글작정자 유저네임, 댓글내용) >> 리플라이 테이블

myBatis 를 쓰면 Join을 이용해 전부를 Select 해와야 한다.
ORM 방식을 사용하면 보드 테이블만 셀렉트 해온다. (Java와 DB 사이에서 JPA가 Java의 요청을 받았을 때, JPA는 보드가 유저라는 오브젝트를 가지고 있으므로 유저테이블도 가져와야 한다고 인식을 함. >> DB에 JOIN문을 날림)

@JoinColumn이 필요할까?? Reply에는 FK가 필요가 없다. 왜? >>

게시글이 있고 누군가 댓글을 하나 썼을 때 replyId가 있다면 그걸 1 이라고 함. 또 다른 사람이 댓글을 쓰면 2가 추가가 됨 >> 1정규화가 깨짐 (하나의 컬럼은 원자성을 가진다)

DB에서 보드 테이블의 정보를 가져올 때 같이 들고와주기만 하면된다.
mappedBy >> 연관관계의 주인이 아니다 (난 FK가 아니다) DB에 컬럼을 만들지 않는다.(Reply 테이블의 매핑한 Board가 FK이다)

@OneToMany >> Board 1건 정보를 들고 올 때, Reply는 많은 건수의 정보를 들고와야 하기 때문에(화면에 댓글이 상세보기/펼치기로 보일 때 >> 필요하면 들고오고 아니면 들고오지 않는다) 기본 패치전략은 LAZY

상세보기(펼치기)가 없는 경우 >> Eager전략으로 바꾼다.

////////////////////////////////////////////////////////////////////////////////////////////

JPA 연관관계에 대해서 참고
https://ict-nroo.tistory.com/127

0개의 댓글

관련 채용 정보