[인프런] 스프링부트 개념정리(이론) - 1

해당 내용은 https://inf.run/xFxo 를 참고하여 작성되었습니다.

 

 

2편은 velog에 정리 했습니다.

https://velog.io/@pnk7038/Inflearn%EC%9D%B8%ED%94%84%EB%9F%B0-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC%EC%9D%B4%EB%A1%A0-

[Inflearn|인프런] 스프링부트 개념정리(이론) - 2

---

스프링

• 프레임워크이다.
• 오픈소스이다.
• IoC 컨테이너를 가진다.
  • Inversion Of Controll => 제어의 역전
  • 주도권이 스프링에게 있다.
    • Class : 설계도
    • Object: 실체화가 가능한 것
    • Instance: 실체화 된 것
  • 개발자가 직접 new로 할당하여 메모리공간에 올라간 객체들을 사용하고 싶은데 매개변수로 넘겨받기가 어려운 단점을 스프링이 극복
  • 스프링이 직접 객체들을 읽고 heap 메모리에 띄워서 관리해준다.
• DI (Dependency Injection) 의존성 주입
  • 스프링이 관리하는 객체를 내가 원하는 모든 곳에서 사용할 수 있다. 다른 곳에서 같은 객체를 사용할 수 있다.
  • 따라서 Single Ton 이라는 것!!
• 스프링은 많은 필터를 가진다.
  • 스프링이 가지는 필터를 사용할 수 있으며 사용되지 않은 필터를 사용할 수도 있고 직접 사용자가 필터를 만들어서 사용할 수도 있다.
  • 톰캣의 필터는 실제로 필터라고 불리며 필터의 기능을 하는 파일이 web.xml이다.
  • 스프링 컨테이너의 필터는 인터셉터라고 불리며 AOP 개념을 갖는다.
• 스프링은 많은 어노테이션을 가진다. (리플렉션, 컴파일체킹)
  • 어노테이션은 컴파일러가 체크할 수 있게 힌트를 주는 주석이므로 컴파일러가 무시하지 않는다. 반대로,그냥 주석은 컴파일러가 무시한다.
  • 만약 @overide로 오버라이딩 메소드를 작성했는데 부모에게 해당 메소드가 없다면 컴파일 에러가 난다. 이것이 컴파일 체킹이다!
  • 스프링에선 어노테이션을 통해 객체를 생성한다.
    • @Componet : 해당 어노테이션이 붙은 클래스를 메모리에 로딩한다.
    • @Autowired : 해당 어노테이션이 붙어있다면 로딩된 객체를 해당 변수에 넣는다.
  • 클래스 내에 어떤 변수가 있는지 분석하는 것을 리플렉션 이라고 한다.
    • 리플렉션을 통해 클래스 내부의 메서드, 필드, 어노테이션을 check 할 수 있다.
    • check해서 있다면 해야 할 일을 지정해줄 수도 있다. 
      • 따라서, 어노테이션 (주석+힌트)
      • 리플렉션 (해당 클래스가 어떤 메소드, 필드, 어노테이션을 갖고있는지 분석하는 기법)
        • 런타임시 분석한다.
•  스프링은 MessageConverter를 가진다. 기본값은 Json
  • 중간언어로 Json을 사용한다. 모든 언어의 사람들이 이해할 수 있는 언어.
    • Ex) 자바 Object > Json > 파이썬 Object
  • messageConverter는 요청, 응답 둘 다의 상황에 JSON으로 변환해준다.
  • [요청/응답] messageconverter로 Jackson 이라는 라이브러리가 Json 데이터로 변환하고 Json 데이터를 변환한다.
  • 굉장히 편리 !!
•  스프링은 BufferedReader와 BufferedWriter를 쉽게 사용 가능
  • 1byte는 통신의 단위.영어 한 문자는 8bit(= 1byte)로 256가지 문자를 표현할 수 있다. 한국어는 16bit
  • 요즘은 유니코드에서 정한 UTF-8 인코딩 방식으로 3byte 통신을 지향한다. 
  • Byte Stream을 통해 통신을 하는데 자바가 InputStream을 통해 byte를 그대로 받는다.
    • byte를 다시 문자(char)로 변형해서 사용해야 하는데 번거로움
    • 따라서 InputStreamReader 클래스를 사용한다. 
      • byte를 문자로 바꿔서 변환한다. 배열로 여러개의 문자도 받을 수 있다. 단, 배열의 크기를 지정해줘야 하는 단점때문에 메모리 낭비가 일어나므로 InputStreamReader도 잘 사용하지 않는다.
    • BufferedReader로 데이터를 받게된다면 가변 길이의 문자를 받을 수 있다.
      • 만약 데이터를 BufferedReader로 받게된다면(예시 JSP: requeset.getReader()를 사용하면 해당 BufferedReader가 일을 한다.)
      • JSP에는 내장객체로 out이 있는데 이게 바로 BufferedWriter이다.
    • 그러나 BufferedWriter가 내려쓰기 기능이 없어서 PrintWriter를 더 주로 사용한다. 둘은 내려쓰기 유무 차이 일뿐이다.
      • 함수로는 Print()와 Println()을 제공하는데 내려쓰기를 사용하고 싶다면 후자를 사용하면 된다.
  • 즉, BufferedWriter라는 것은 byte를 통해 데이터를 전송할때 문자열로 가변 길이의 데이터를 사용할 수 있게 해주는 클래스이다.
  • 이 둘을 통해 통신을 할때 직접 구현할 필요없이 데이터를 전송가능
    • [데이터 전송] 어노테이션(@ResponseBody)을 사용하면 BufferedWriter가 동작.
    • [데이터 수신] 어노테이션(@RequestBody)을 사용하면 BufferedReader가 동작.
•  스프링은 계속 발전중

@Componet가 붙어있는 클래스를 IoC 기법을 통해 heap 메모리에 자동으로 올린다.

타입으로 IoC가 읽어들인 객체를 찾는다. 같은 타입인 A가 있으므로 a에 A가 들어간다.(=> DI 기법)

messageConverter 작동 방식

---

JPA

• Java Persistence API
  • Persistence(영속성): 데이터를 생성한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터 특성
  • 영속성은 파일 시스템, 관계형 데이터 베이스, 객체 데이터 베이스등을 활용하여 구현
  • 자바에 있는 데이터를 영구히 기록할 수 있는 환경을 제공하는 API
    • API란? Application Programming Interface
    • 좋은 프로그램을 공유해줄게. 대신 인터페이스라는 약속을 지켜서 사용해라.
    • 상하관계가 존재하는 약속이 인터페이스
    • 인터페이스와 반대로 프로토콜은 상하관계가 존재하지 않고 동등한 관계이다. 서로에게 잘 맞는 약속을 정해야 한다.
  • 자바 프로그램을 할 때 영구적으로 데이터를 저장하기 위해 필요한 인터페이스가 JPA이다.
• JPA는 ORM 기술
  • Object Relational Mapping: object를 db에 연결하는 방법론
  • 모델링: 추상적인 개념을 현실세계로 뽑아내는 것
  • 보통은 DB 테이블을 먼저 설계하고 자바의 class를 모델링(TRM)하는데 이를 JPA 인터페이스를 통해 반대로 진행할 수 있다. 이것이 바로 ORM
  • ORM은 자바의 class를 먼저 만들고 JPA의 인터페이스의 규칙을 지켜 DB의 테이블을 자동으로 만들 수 있는 방식이다.
• JPA는 반복적인 CRUD 작업을 생략하게 해줌
  • select 1건, 전체 ... delte 1건, update 1건... 등 이런 자주 발생하는 CRUD가 많이 발생한다. 이를 위해 자바가 DB에 연결을 요청하고 DB가 세션을 오픈하여 커넥션을 가진다. 
    • 커넥션을 가진 뒤 2번째 요청에는 query를 전송할 수 있고 이를 통해 DB 테이블의 데이터를 만들고 자바에 다시 응답할 수 있다.
    • 단, 테이블의 데이터와 자바의 데이터 타입이 다르므로 자바는 해당 데이터를 받아서 자바 Object로 변경해야 한다. 
  • 이런 것들이 반순 반복 작업이다. 
  • 이 작업들을 줄여주는게 바로 JPA이다!!
    • JPA를 사용하면 전송된 query에 대한 응답이 있을 때 받은 데이터를 자바 object로 변경하고 연결 세션, 커넥션을 끊고 연결하는 작업을 함수 1개로 제공해준다.
    • 즉, 함수만 사용한다면 이런 반복적인 코드들을 사용하지 않아도 된다.
• JPA는 영속성 컨텍스트를 가짐
  • 컨텍스트(Context)는 그 대상의 모든 정보라고 보면 된다.
  • 자바가 DB에 저장된 일련의 모든 정보를 영속성 컨텍스트를 통해 확인할 수 있다.
  • 자바가 저장해야 하는 모든 메타 데이터 정보들을 영속성 컨텍스트가 가지고 있으므로 자바는 항상 영속성 컨텍스트를 통해 DB에 데이터를 저장하고 DB도 영속성 컨텍스트를 통해 데이터가 자바에 전달된다.
  • 영속성 컨텍스트에서 일어나는 일들은 전부 자동으로 처리된다.
  • 영속성 컨텍스트에 있는 데이터와 DB안에 있는 데이터는 동기화된다.
    • 즉, 영속성 컨텍스트에 있는 데이터를 지우면 DB안에 있는 데아터도 삭제된다.
  • 자바에서 select를 욫어하면 DB로 바로가는 것이 아니라 먼저 영속성 컨텍스트로 접근한다.
    • 만약 영속성 컨텍스트에 과일 데이터가 없고 DB에 과일 데이터가 있다면 영속성 컨텍스트는 DB에 가서 과일 데이터를 요청한다. 
    • DB에 요청하여 받은 과일 데이터를 자바 Object로 바꾼 영속성 컨텍스트에 저장한다.
    • 다시 자바에 영속성 컨텍스트에 저장된 과일데이터를 전달한다. 
    • 따라서 자바, 영속성 컨텍스트, 과일 데이터의 내용은 사과로 전부 일치한다.
      • 만약 자바에서 과일데이터의 내용을 사과에서 딸기로 변경한다면?
      • 영속성 컨텍스트에 있는 과일데이터가 딸기로 변경되고 DB에 변경된 내용을 커밋하게 된다면
      • DB에 insert가 아닌 update문이 자동으로 호출되어 딸기로 변경되게 된다.
• JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론 제공 (DB는 객체저장 불가, 자바는 객체저장이 가능하다.)
  • 테이블에는 기본 자료형밖에 사용할 수 없다. 따라서 2번의 select나 join을 통해 해결해야 하는 단점이 있다.
    • 이런 방식을 사용한다면 DB 테이블에 맞춘 클래스(모델)를 만들 수 밖에 없다.
  • 그러나, 자바에서는 기본 자료형이 아닌 Object를 저장할 수 있다.  이것이 바로 OOP의 장점!!
    • 자바가 주도권을 쥐고있는 모델을 만들 수 있다.
    • 이렇게 만들어진 데이터에 JPA가 알아서 데이터를 넣어줄 수 있다. 이것이 바로 ORM~!
• JPA는 OOP의 관점에서 모델링을 할 수 있게 함 (상속, 콤포지션, 연관관계)
  • 콤포지션(결합) Ex) 엔진과 자동차
    • Class Car에 int id, String name, String color, Engine engine;
    • Class Engine은 int id, int power;
    • JPA 자동생성을 통해 OOP관점에서 Car 테이블을 만들 수 있다. 컬럼으론 id, name, color, engineId
    • 마찬가지로 OOP관점에서 만들어진 Engine 테이블 컬럼으론 id와 power
    • Car와 Engine에 둘 다 날짜를 만들어 싶은데 겹치는 변수이므로 클래스로 만들어준다
    • Class EntityDate에 Timestamp createDate, Timestamp updateDate;
    • 그리고 이 클래스를 Car와 Engine이 extends(상속) 받아서 사용한다.
• JPA는 방언 처리가 용이하여 Migration과 유지보수에 좋음
  • 스프링에서 DB에 접근할때 JPA를 사용하는데 JPA는 추상화 객체를 바라보기 때문에 이 추상화 객체를 MySQL로 바꾸든 Oracle로 바꾸든 상관없이 DB에 접근해서 사용할 수 있다.
    
    • 이것이 바로 방언 처리가 용이한 것이다.
• 쉽지만 어렵다 

OOP를 이용하여 모델에 Object를 저장할 수 있다. 이것이 ORM의 장점.