스프링은 프레임워크이다.
스프링은 오픈소스이다.
스프링은 IoC 컨테이너를 가진다.
스프링은 DI를 지원한다.
스프링은 엄청나게 많은 필터를 가지고 있다.
스프링은 엄청나게 많은 어노테이션을 가지고 있다. (리플렉션, 컴파일체킹)
스프링은 MessageConverter를 가지고 있다. 기본값은 Json
스프링은 BufferedReader와 BufferedWriter를 쉽게 사용할 수 있다.
오픈소스 프레임워크
소스코드 공개-> 내부를 내가 뜯어고칠 수 있음.
IOC (Inversior of Control)
class 설계도
object 실체화가 가능한 것
instance
Dependency Injection지원 (의존성 주입)
스프링이 스캔을 해서 오브젝트를 메모리에 띄었기 때문에 스프링이 관리.
재화의 역전)
내가 원하는 모든 클래스, 메소드에서 가져와서 사용할 수 있음. => DI
single ton designe pattern
필터 : 문지기 개념
스프링 자체 필터 내장, 사용하지 않는 필터를 사용한다고 정의, 내가 직접 필터 설정 가능
톰캣필터
web.xml
intercepter (AOP)
compile checking?
annotation? (주석+힌트) 컴파일러가 무시하지 않음.
// 컴파일러가 무시하는 게 주석.
스프링에서는 어노테이션을 이용해서 주로 객체를 생성함.
@Component 클래스 메모리에 로딩.
IoC heap메모리에 스캔해서 @Component 로딩함
@Autowired 로딩된 객체를 해당 변수에 집어 넣어라
리플렉션: 어떤 어노테이션이 있는지, 필드가 있는지, 메서드가 있는지 체킹하고 있다면 무엇을 할 건지 설정할 수 있음.
분석하는 기법-> 런타임때 분석.
Message Converter?
옛날에는 xml로 했는데 요즘은 주로 Json사용
자바프로그램을 누군가에게 전송할때 중간 Json데이터로 바꿔서 던져주는 게 Message Converter.
자바프로젝트->파이선프로그램
전송할때 (request) 요청 시에 데이터를 Json으로 바꿔주는 게 Message Converter : 스프링 라이브러리로 존재, 기본 Jackson설정. 잭슨은 Json으로 바꿔줌.
마찬가지로 응답 받을때도 (response) Json데이터로 던질 때 MessageConverter가 바꿔줌.
유니코드 : UTF-8
Byte Stream
inputStream 으로 데이터를 읽으면 바이트 통신하고 있으니까 바이트로.
바이트는 문자가 아니니까. char로 변환해서 받아야 하는데 이러면 복잡하니까
inputStream Reader로 문자를 감싸서 (배열)
배열로 감싸서 받을 때는 배열의 크기를 정해야 하는데 통신할 때마다 배열의 크기를 알 수 있으니까 결국 사용하는 건
BufferedReader를 사용. 가변길이의 문자를 받을 수 있음.
BufferedReader -> request.getReader()
PrintWriter(=BufferedWriter) -> print(), println()
JSP에서는 out이라는 내장객체가 있는데 이 자체가 BufferedWriter와 같음.
전송단위가 문자열로 가변길이의 데이터를 쓰게 해주는 클래스.
BufferedReader, BufferedWriter로 통신.
어노테이션 제공
@ResponseBody = BufferedWriter
@RequestBody = BufferedReader
JPA
JPA란 Java Persistance API이다.
JPA는 ORM 기술이다.
JPA는 반복적인 CRUD 작업을 생략하게 해준다.
JPA는 영속성 컨텍스트를 가지고 있다.
JPA는 DB와 OOP의 불일치성을 해결하기 위한 방법론을 제공한다. (DB는 객체저장 불가)
JPA는 OOP의 관점에서 모델링을 할 수 있게 해준다. (상속, 컴포지션, 연관관계)
방언처리가 용이하여 Migration하기 좋음. 유지보수에서 좋음.
영속성(persistance)는 데이터를 생서한 프로그램의 실행이 종료되더라도 사라지지 않는 데이터의 속성을 의미한다. 파일 시스템, 관계형 데이터베이스 혹은 객체 데이터베이스 등을 활용하여 구현한다.
영속성:RAM(전기)-휘발성->하드디스크에 기록(비휘발성이니까 영구적 저장)
API : Application Programming Interface
프로토콜 / 인터페이스
권리가 동등한 약속 / 상관관계가 존재하는 약속
world wide web
수많은 프로토콜들이 모여서 만들어진 게 인터넷
=> JPA란 자바 프로그래밍을 할 때 영구적으로 데이터를 저장하기 위해 필요한 API.
ORM : Object Relational Mapping
추상적인 걸 현실적인 개념으로 뽑아내는 걸 모델링.
자바의 데이터타입과 DB 데이터 타입이 다르니까
클래스를 통해서 DB 데이터를 모델링해야함.
Class Team S
int id;
String name;
String year;
// DB세상에 있는 데이터를 자바 세상에 모델링하는 과정.
// 반대로 얘를 먼저 만들고 자동으로 DB에 생성할 수 있음. JPA의 인터페이스. => ORM 자바에서 디비로 세션오픈하고 커넥션 후 쿼리전송.
데이터를 만들어내면 자바로 응답.
자바 오브젝트로 변경해야 하는데 이게 단순한 반복로직.
이런 일을 줄여주는 게 JPA. 이 모든 일을 함수 하나로 제공.
Insert C
Select, Select All R
Update U
Delete D
컨텍스트? context 대상의 모든 정보.
자바가 디비에 접근해서 하는 모든 과정(select, update등)을 모두 영속석 컨텍스를 통해 모두 전달됨.
HTTP?
스프링부트의 동작원리
- 내장 톰캣, 톰캣 따로 설치할 필요 없이 바로 사용 가능.
socket:운영체제가 가지고 있는 것.
메세지 교환하기 위해서는 운영체제가 가지고 있는 소켓을 이용하면 되는데
포트 열고 소켓오픈-> 포트번호와 ip주소 넣고 연결. ->연결이 되는 순간 메세지를 주고 받을 수 있는 통신 가능. (메인스레드)
첫 포트번호는 연결의 용도로만 쓰고 새로운 소켓 생성->새로운 소켓으로 메세지 통신을 지속적으로 할 수 있음.
새로운 소켓 만들 때는 새로운 스레드를 만들어야함. 이게 반복되는 게 소켓통신.
부하가 크다. 느려짐.
http통신은 연결을 지속시키지 않고 끊어버리는 stateless방식 사용.
문서를 전달하는 통신.
한번 연결되고 나서 끊기니까 부하가 적긴 한데 주고받을때 누가 누군지 모름.
운영체제가 가지고 있는 소켓이라는 애를 이용해서 만들어진 게 http인데
시스템이 가지고 있는 걸 콜 해서 만들어졌다고 해서 시스템콜이라고 불리는데
톰캣과 웹서버에 대한 차이를 알아야하고 웹서버가 무엇인지 정확히 알아야함.
web server?
인터넷 통신을 활용해서
을이 갑에게 request(요청) 요청할때는 ip주소를 알아야함
또 어떤 동영상이 필요한 지 정확하게 명시 = url(location) (자원을 요청하는 주소)
->해당데이터 response(응답)
을의 응답을 하기 위해서는 소켓을 써야함. -> 언제나 데이터를 전달해줄 수 있음.
요청시마다 변하는 자원이 아닌 정적자원(static 자원).
아파치 라는 웹서버를 주로 사용하는데
내 컴퓨터 내에 특정 폴더를 지정하고 이걸 사람들에게 공유.
.jsp(자바코드)
아파치는 자바코드 이해하지 못함. 그러니까 톹캣을 달아서
아파치가 이해하지 못하는 파일이 request가 오면 톰캣에게 넘김.
톰캣은 .jsp안에 있는 자바코드를 컴파일하고 컴파일이 끝나면 그 데이터를 .html에 덮어씌움. (웹브라우저)
html, js, css, avi 정도만 이해할 수 있음 - 웹브라우저
웹브라우저는 jsp이해못함. jsp->html 변환해서 response 해주는 게 톰캣의 역할.
서블릿컨테이너?
url location 자원 접근
uri idenfy 식별자 접근
특정한 파일 요청을 할 수 없음.
요청 시에는 무조건 자바를 타야함.
톰캣이 자바를 컴파일 할 수 있으니까 http://www.~~ a.png
http://www.~~~/picture/a
web.xml
관문?
- ServletContext초기 파라미터
- Session의 유효시간 설정
- Servlet/JSP 정의, 매핑
- Mime Type 매핑
- Welcome File List
- Error Pages 처리
- 리스너/필터 설정
- 보안
왜?! 필요한가
엄청나게 큰 성이 있는데 이 성의 입구, 문지기.
이 문지기는 스스로 일을 할 수 없음.
관리자 필요. 관리자가 문지기에게 이거저거해라 하고 리스트를 줌.
관리자마다 바뀔 수 있지만 문지기는 바뀌지 않음.
- 초기 파라미터는 초기에 설정해놓으면 어디서든지 이용할 수 있음.
인증을 통해 들어오는 게 session. - 세션:3일로 설정하면 3일 후에 추방.
세션을 늘리려면 문지기에게 확인받고 연장 - 요청한 로케이션, 식별자가 확인하고 어디로 가야 하는지 알려줌, 매핑
- get방식:데이터를 가지고 오지 않음. select
쌀을 가지고 왔다면 쌀창고로 이동해->쌀창고로 데이터를 보냄->데이터 가공->
Mime Type 확인! 내가 뭘 들고왔는지 확인. 이거 틀리면 에러남. - 아무이유없이 들어온 애들은 일단 광장으로 보내.
광장에는 일거리가 많으니까. 관리자가 누구인지에 따라 설정할 게 많음. - 이상한 주소 니가 모르는 주소로 오는 애들은 다 에러페이지로 던져.
- 필터? a의 신분을 확인하고 이상한 애면 아예 안받는 것. 혹은 총 가지고 왔으면 총 뺏고 들여보냄.
리스너? 술 잘먹는 사람 찾아놔. 저 너무 일 많아서 못해요->리스너 생성.
리스너는 그럼 술 잘먹는 사람만 찾는 대리인.
다른 거 안보고 술 잘먹으면 걍 데려감 - 성 보호.
여기에서 Servlet/JSP 매핑시(web.xml에 직접 매핑 or @WebServlet 사용) 에 모든 클래스에 매핑을 적용시키기에는 코드가 너무 복잡해지기에 FrontController패턴을 이용함.
FrontController?
최초 앞단에서 request요청을 받아서 필요한 클래스를 넘겨줌. 왜? web.xml에 다 정의하기가 힘드니까. 이 때 새로운 요청이 생기기 때문에 request와 response가 새롭게 new 될 수 있음. 그래서 아래의 RequestDispatcher가 필요.
request요청(.do 특정주소)이 들어오면 바로 자원의 접근을 하지 못하니 톰캣으로 감. 최초에 request와 respons객체를 만듦.
FrontContorller가 자원에 접근을 할 수 있게 또 다시 request.
RequestDispatcher?
필요한 클래스 요청이 도달했을 때 FrontController에 도착한 reuqest와 response를 그대로 유지시켜준다.
데이터를 들고 페이지 이동 가능
DispatchServlet?
FrontCtrt패턴을 직접 짜거나 RequestDispatcher를 직접 구현할 필요가 없음. 왜냐면 스프렝에서는 DispatcherServlet이 있기 때문. DispatchServlet은 FrontCtr패턴+RequestDispatcher.
DispatchServlet이 자동생성되어 질 때 많은 객체가 생성(IoC) 보통 필터들. 해당 필터들은 내가 직접 등록할 수 있고 기본적으로 필요한 필터들은 자동 등록이 됨.
궁극적인 목적은 주소분배.
@Controller
@RestController
@Configration
@Repository
@Service
@Component
이런것들이 붙어있는 걸 dispatchServlet
컴포넌트 스캔으로 스캔하고 주소분배.
web.xml이 contextLoaderListener
DB에 관련된 것은 contextLoaderListener
root-applicationContext파일을 xml파일로 커스텀할 수도 있고 작업파일로 커스탐할 수 있는데 공통적으로 사용하는 애들을 띄어줌,
ApplicationContext
수많은 객체들이 ApplicationContext에 등록된다. 이것을 IoC라고 하는데 제어의 역전을 의미한다. 개발자가 직접 new를 통해 객체를 생성하게 된다면 해당 객체를 가르키는 레퍼런스 변수를 관리하기 어렵다. 그래서 스프링이 직접 해당 객체를 관리한다. 이 때 우리는 주소를 몰라도 된다. 왜냐면 필요할 때 DI하면 되기 때문. 필요한 곳에서 ApplicationContext에 접근하여 필요한 객체를 가져올 수 있다. ApplicationContext는 싱글톤으로 관리되기 때문에 어디에서 접근하든 동일한 객체라는 것을 보장해준다.
ApplicationContext는 두 가지가 종류가 있는데
1. root-applicationContext
: Service, Repository등을 스캔하고 DB관련 객체를 생성. (스캔? 메모리에 로딩한다는 뜻), 해당 파일은 ContextLoaderListener에 의해 실행. ContextLoaderListener를 실행해주는 건 web.xml이기 때문에 root-applicationContext는 servletapplicationContext보다 먼저 로드됨.
- servlet-applicationContext
: ViewResolver, Intercepter, MultipartResolver객체를 생성하고 웹과 관련된 어노테이션 Controller, RestController를 스캔. 해당 파일은 DispatchServlet에 의해 실행됨.
@Bean
필요할 때 호출해서 메모리에 로드. IoC lazy-loading.
