필드 주입과 생성자 주입, rest, @RestController
히카리풀
히카리풀 : 스프링부트에서 제공하는 커넥션 풀
timeout- 커넥션 줬을 때 몇초간 기다릴거야
idel timeout-반납된 커넥션이 놀고있는기간 이후엔 죽임
max lifetime-기다리고있다가 돌아오면 죽임
---
에러가 났을 때 특정 페이지로 보내는 법ㅂ
스프링부트에는 web.xml이 없어서 다른 방법으로 해줘야함
modelandview는 서비스가 처리할 일이 있을 때 사용
---
rest
: URI를 통해 자원을 명시하고, 어떤걸 요청하는지 알게한다
restful은 ajax를 뜻하는게 아님, 얘의 시초는
요청할때 파라메터 달고다니는게 지저분하고 뭘요청하는지 인식 어려움 -><
url만 봤을때 뭘요청하는지 알게하자 : restful
url에 많은 정보를 주고 파라메터를 던진다
요청하는 쪽과 서버가 다르다는 특징이 있다
외부에서 요청할 때 직관적이어야 할 때 유용함 ex 공공데이터한테 요청할 때
api는 복잡한걸 단순하게하는 장치, 문서의 의미
restful api (프론트 신경안써 -> jsp를 사용하지 않음
@RestController 쓰는 이유
ajax에 값을 보내줘야해서, @Response body 기능도 같이 하는 컨트롤러여서 사용함
근데 얘는 페이지 이동이 불가능함 -> 메서드의 데이터타입을 ModelAndView로 해놔
복잡한 JSON 처리하는 법
키에 여러가지 밸류값(배열)이 들어가고 그 배열 안에 또 오브젝트가 들어가면?(중학교, 고등학교, 대학ㄱ교 등)
조건들----
type : 'POST', (데이터가 길어지니까-> get은 주소에 보이니까 잘릴 수 있음)
data: 문자열 형태 (json은 특수문자가 많아서 url에 붙였을 때 잘릴 수 있어서 )
contentType:'application/json; charset=utf-8',(text.html이 아니라 json이라고 contentType을 명시해줘야함)
---
requestparam아니고 body로 받기
파라메터는 바디 영역에 담는 경우가 있고 파라메터 영역에 담는 경우가 있는데 이 경우엔 전자임 그래서 걍 @RequestBody 쓰면 됨
필드 주입과 생성자 주입
필드주입 : @Autowired TeamService service;
생성자 주입 : public TeamController(TeamService service) {
this.service = service;
}
//생성자 주입이 왜 좋은가?
1. final을 쓸 수 있으므로 불변성을 보장한다(필드주입시 못 씀)
2. 객체간 순환참조를 방지한다
//필드 주입이 어떤 문제가 있는가
순환 참조를 조기에 발견할 수 없다는 것 가장 큰 문제
Controller -> Service -> DAO 같은 일방향 구조로는 순환참조가 발생하지 않는다.
서비스끼리 참조하는 경우 문제가 발생할 수 있다
필드주입 방식은 서비스 실행후 실제 문제 발생시까지 (메모리가 가득 차는 stack over flow라는 문제) 알 수가 없다.
생성자 주입은 순환참조 발생시 빌드 전에 미리 알 수 있다 (컴파일 에러가 남)
lombok의 @RequireAgrsConstructor를 사용하면 같은 효과를 낸다 (이런 어노테이션을 보면 아 생성자 주입을 했구나)