[스프링의 정석 이론 요약]
[Client와 Server에 대해 아는대로 적어라]
역할에 따라 클라이언트와 서버를 구분한다.
클라이언트는 서비스를 서버에 요청하고, 응답을 받는 애플리케이션이고, 서버는 서비스를 클라이언트에 제공하는 애플리케이션이다.
서버의 종류는 제공하는 서비스에 따라 다르며 각 서버는 포트번호로 구분된다. 서버가 요청을 받기 위해서는 서버와 포트가 binding되어있고, Listening상태여야 한다.
[WAS에 대해 아는대로 적어라]
WAS는 웹 애플리케이션을 서버로 웹 프로그램을 서비스하는 서버이다. 서버에 프로그램을 설치해놓고, 클라이언트가 이 프로그램을 사용할 수 있게 하는 것으로, 이를통해 클라이언트에서 원격으로 프로그램 호출이 가능하다.
[톰캣에 대해 아는대로 적어라]
톰캣은 Server, Service, Engine, Host, Context, Servlet으로 구성되어 있다. 서버에 요청이 들어오면 Server의 쓰레드풀에서 쓰레드를 할당받고, Service에서 프로토콜에 맞는 Connector를 연결한다. 그 다음 Engine, Host, Context를 거쳐서 요청으로 받은 URL과 연결된 Servlet이 작업을 수행 후 클라이언트로 응답을 전달한다.
[MVC패턴에 대해 아는대로 적어라]
입력, 처리, 출력을 분리하고 Model로 데이터를 전달.
요청이 들어오면 DispatcherServlet이 HandlerMapping에게 요청의 URL과 맵핑된 메서드 정보를 받아서, HandlerAdapter를 거쳐 컨트롤러로 Model객체를 보낸다. 컨트롤러에서 작업 후 뷰 이름을 반환하고, 반환된 뷰 이름을 InternalViewResolver에게 물어서 정확한 뷰 이름을 얻는다. 만약 JSP라면 JSTL뷰를 통해 해당 뷰로 Model을 전송하고, 해당 뷰에서 클라이언트로 응답을 전달한다.
[JSP에 대해 아는대로 적어라]
서블릿으로 변환된다.
기본객체로 request, response, pageContext, session, application 등이 있다.
Http는 stateless이므로 저장소가 4개가 있다. 접근범위와 생존기간에 따라 구분되고 map으로 되어있다.
pageContext는 lv를 저장하고 같은 page안에서 사용할 수 있다.
application은 접근범위가 webApp전체에서 접근가능하고 1개만 존재한다.
session은 클라이언트마다 1:1로 존재하는 개별저장소이다. 서버의 부담에 제일 크므로 최소한의 data만 저장해야 한다.
request는 요청할 때마다 생기고, 각 요청은 독립적이다. session을 통해 request를 묶을 수 있다.
[쿠키와 세션에 대해 아는대로 적어라]
쿠키는 이름과 값의 쌍으로 구성된 작은 정보로 클라이언트 식별기술이다. 아스키문자만 사용가능하므로 한글은 URL인코딩이 필요하다. 서버에서 생성해서 브라우저에 저장된다. 유효기간을 설정할 수 있다.
요청이 들어오면 서버에서 쿠키를 생성해서 응답 메세지로 브라우저로 전송하고, 그 다음부터 요청을 서버에 보낼 때마다 자동으로 쿠키를 같이 전송한다. 이 쿠키를 통해 클라이언트를 구별할 수 있다. 로그인의 아이디기억에 사용할 수 있다.
세션이란 서로 관련된 요청과 응답을 하나로 묶은 것으로 쿠키를 사용한다.
브라우저에서 요청을 서버로 보내면 서버는 무조건 세션객체를 만들어서 세션ID를 응답으로 보내고 브라우저에는 쿠키가 저장된다.
그 다음부터는 요청에 쿠키를 포함해서 서버로 보내고, 이 요청들은 세션이 종료되기 전까지 하나의 세션아이디로 묶이게 되고, 같은 세션 저장소를 사용할 수 있게 된다.
세션이 종료되면 세션 저장소는 자동으로 제거된다.
만약 쿠키를 생성하지못하게 브라우저에서 막아놓으면 c:url태그를 적용한 곳에 세션아이디를 붙여서 요청할 때마다 보낸다. 세션을 종료할 때는 수동종료와 자동종료가 있다.
JSP에서 세션을 시작할지 안할지 정할 수 있다.
registerForm이나 index, loginForm에는 세션을 false로 한다.
쿠키는 브라우저에 저장하고 따라서 서버에 부담이 없다. 보안에 불리하고 서버 다중화에 유리하다.
세션은 서버에 저장하므로 서버의 부담이 크다. 보안에 유리하고, 서버 다중화에 불리하다.
[예외처리에 대해 아는대로 적어라]
예외처리를 위한 메서드를 작성하고 @ExceptionHandler를 붙인다. @ControllerAdvice로 전역 예외처리 클래스를 작성할 수 있다.
@ResponseStatus는 예외처리 메서드 앞에 붙여서 상태코드를 200에서 400이나 500으로 변경하거나, 사용자 정의 예외클래스에 붙여서 500을 다른 상태코드로 변경할 수 있다.
web.xml에 에러코드별로 등록할 수 있고, sevlet-context.xml에는 에러종류별로 보여줄 뷰를 등록할 수 있다.
[WebDataBinder에 대해 아는대로 적어라]
데이터 타입변환과 데이터 검증에 사용된다.
해당 컨트롤러의 검증할 객체 앞에 @Valid를 붙이고 뒤에는 BindingResult result를 붙인다. 이렇게 하면 에러가 발생해도 컨트롤러에서 처리하도록 한다.
@InitBinder를 메서드앞에 붙이고, 매개변수를 WebDataBinder binder로 해서 데이터변환과 Validator를 등록할 수 있다.
Validator는 Validator 인터페이스를 구현해서 작성한다.
메세지는 message.properties파일을 만들어서 작성한다.
[Spring DI에 대해 아는대로 적어라]
@Component - @Component를 메타 에너테이션으로 가지고있는 @Controller, @ControllerAdvice, @Repository, @Service는 component-scan태그로 자동으로 bean으로 등록시킬 수 있다.
@Autowired - bean으로 등록된 객체를 DI로 주입받는다. by Type으로 주입받고, 타입이 일치하는것이 여러개 있으면 @Qualifier을 추가로 붙여서 이름을 지정할 수 있다.
@Resource - by Name으로 주입받고, 이름을 적지 않으면 타입의 첫글자를 소문자로한 것을 이름으로 찾는다.
[ApplicationContext에 대해 아는대로 적어라]
AC는 Root AC, Servlet AC가 있다.
web.xml를 보면 먼저 root-context.xml를 이용해서 Root AC를 생성하고 그다음 DispatcherServlet이 초기화되면서 servlet-context.xml을 이용해서 Servlet AC를 생성한다.
톰캣을 시작할 때 각 AC의 로그를 보고, 그 부분에 에러가 발생했다면 어디가 문제가있는지 단서가 될 수 있다.
Servlet AC가 자식, Root AC가 부모인 관계이며,
자식을 먼저 찾고, 부모를 찾으므로 자식인 Servlet AC에는 개별적인 WEB관련 bean을 넣고, Root AC에는 공통적인 non-web관련 bean을 넣는다.
[TDD에 대해 아는대로 적어라]
@Runwith - 재사용할 수 있는 하나의 AC를 자동으로 생성.
@ContextConfiguration - 생성된 AC에 사용할 설정파일 위치를 지정.
[Transaction에 대해 아는대로 적으시오.]
더이상 나눌수없는 작업의 단위로써 계좌이체의 경우 출금과 입금이 하나의 Tx로 묶여야한다. 즉 둘 다 성공하지 않으면 원래상태로 rollback되어야 한다.
Tx의 속성으로 ACID가 있다.
Atomicity - 원자성. 나눌수 없는 하나의 작업으로 다뤄져야한다.
Consistency - 일관성. Tx의 수행 전과 후가 일관된 상태를 유지해야 한다.
Isolation - 고립성. 각 Tx는 독립적으로 수행되어야 한다.
Durability - 영속성. 성공한 Tx의 결과는 유지되어야한다.
-
Commit - 작업 내용을 DB에 영구적으로 저장.
-
Rollback - 최근 변경사항을 취소.(마지막 커밋으로 북귀)
-
자동 커밋, 수동 커밋
-
Tx의 Isolation level
- read uncommitted - 커밋되지 않은 데이터도 읽기 가능.
- read committed - 커밋된 데이터만 읽기 가능.
- repeatable read - Tx가 시작된 이후 다른 Tx는 변경은 무시됨.
- serializable - 한번에 하나의 Tx만 독립적으로 수행.
-
@Transactional
TransactionManager를 bean으로 등록하고, annotation-driven에 등록해서 @Transactional를 사용할 수 있다.
AOP를 이용해서 핵심기능과 부가기능을 분리한다.
클래스, 메서드, 인터페이스에 붙일 수 있다. -
@Transactional의 속성
propagation - Tx의 경계를 설정.
isolation - Tx의 isolation level을 지정.
readOnly
rollbackFor - Exception예외 발생시 사용.
noRollbackFor
timeout -
Propagation속성의 값
REQUIRED - Tx이 진행중이면 참여하고, 없으면 새로운 Tx를 시작.(기본값)
REQUIRES_NEW - Tx이 진행중이던, 아니던 항상 새로운 Tx를 시작.(Tx안에 다른 Tx생성)
NESTED - Tx이 진행 중이면, Tx의 내부 Tx로 실행.(Tx안에 subTx 생성)
[AOP에 대해서 아는대로 적으시오]
AOP란 관점 지향 프로그래밍으로 변경에 유리한 코드를 만들기 위해 핵심기능과 부가기능을 분리해서 핵심기능에 동적으로 부가기능을 추가해주는 기술이다.
-
AOP관련 용어
target - 핵심기능. 부가기능이 추가될 객체.
advice - target에 동적으로 추가될 부가기능.
proxy - target에 advice가 동적으로 추가되어 생성된 객체.
weaving - target에 advice를 추가해서 proxy를 만드는 것.
join point - advice가 추가될 대상.
pointcut - join point를 정의한 패턴. -
Advice의 종류
@Before - 메서드의 맨 앞에 추가되는 advice.
@After - 메서드의 맨 끝에 추가되는 advice.
@Around - 메서드의 맨 앞과 맨 끝에 추가되는 advice.
@AfterReturning - 예외가 발생하지 않았을 때 실행되는 advice.
@AfterThrowing - 예외가 발생할 때 실행되는 advice.
[각 계층에 대해 아는대로 적어라]
-
@Controller
Presentation Layer.
서비스 계층을 DI로 주입받고, 서비스 계층을 호출만 한다. -
@Service
Business Layer.
DAO를 주입받고, DAO를 호출만 한다.
Tx를 적용하기 적합하다. -
DAO - @Repository
Data access Object.
DB에 저장된 데이터에 CRUD를 수행.
DB테이블당 하나의 DAO를 작성.
계층을 나눠서, 관심사의 분리, 중복코드 제거를 통해 변경에 유리.
