리액티브 시스템 리액티브 시스템이란 클라이언트 요청에 바로 응답을 해주는 시스템을 말한다. 리액티브 시스템의 특징은 다음과 같다. 응답성이 높다. 탄력적이고 유연하다. 메시지 기반으로 통신한다. 리액티브 프로그래밍 리액티브 프로그래밍이란 리액티브 시스템을 구축하는 데 필요한 프로그래밍 모델을 말한다. 리액티브 프로그래밍의 특징은 다음과 같다. 데이터 소스에 변경이 있을 때마다 데이터를 전파 선언형 프로그래밍 패러다임 : 실행할 동작을 구체적으로 명시하지 않고 목표만 정의함 함수형 프로그래밍 기법 사용 리액티브 스트림즈(Reactive Streams) 리액티브 스트림즈란 리액티브 프로그래밍을 표준화한 명세를 말한다.

프록시 패턴 1 2 3 4 package hello.proxy.pureproxy.proxy.code; public interface Subject { String operation(); } 예제에서 Subject 인터페이스는 단순히 operation() 메서드 하나만 가지고 있다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 package hello.proxy.pureproxy.proxy.code; import lombok.extern.slf4j.Slf4j; @Slf4j public class RealSubject implements Subject { @Override public String operation() { log.info("실제 객체 호출"); sleep(1000); return "data"; } private void sleep(int millis) { try { Thread.

템플릿 메서드 패턴 템플릿은 기준이 되는 거대한 틀이다. 템플릿이라는 틀에 변하지 않는 부분을 몰아둔다. 그리고 일부 변하는 부분을 별도로 호출해서 해결한다. 템플릿 메서드 패턴은 부모 클래스에 알고리즘의 골격인 템플릿을 정의하고, 일부 변경되는 로직은 자식 클래스에 정의하는 것이다. 이렇게 하면 자식 클래스가 알고리즘의 전체 구조를 변경하지 않고, 특정 부분만 재정의할 수 있다. 결국 상속과 오버라이딩을 통한 다형성으로 문제를 해결하는 것이다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 package hello.

Spring에서 사용하는 어노테이션 ‘@Transactional’은 해당 메서드를 하나의 트랜잭션 안에서 진행할 수 있도록 만들어주는 역할을 한다. 이때 트랜잭션 내부에서 트랜잭션을 또 호출한다면 스프링에서는 새로운 트랜잭션이 생성될 수도 있고, 이미 트랜잭션이 있다면 부모 트랜잭션에 합류할 수도 있을 것이다. 진행되고 있는 트랜잭션에서 다른 트랜잭션이 호출될 때 어떻게 처리할지 정하는 것을 ‘트랜잭션의 전파 설정’이라고 부른다. 전파 설정 옵션 트랜잭션의 전파 설정은 ‘@Transactional’의 옵션 ‘propagation’을 통해 설정할 수 있다. 각 옵션은 아래와 같다. REQUIRED (기본값) 부모 트랜잭션이 존재한다면 부모 트랜잭션으로 합류한다.

DispatcherServlet 구조 스프링 MVC는 프론트 컨트롤러 패턴으로 구현되어 있다. 스프링 MVC의 프론트 컨트롤러가 디스패처 서블릿(DispatcherServlet)이다. FrontController 패턴 특징은 다음과 같다. 프론트 컨트롤러 서블릿 하나로 클라이언트의 요청을 받음 프론트 컨트롤러가 요청에 맞는 컨트롤러를 찾아서 호 입구를 하나로 하여 공통 처리 가능 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿을 사용하지 않아도 됨 DispacherServlet는 부모 클래스에서 HttpServlet 을 상속 받아서 사용하고, 서블릿으로 동작한다. 상속관계는 다음과 같다. DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet

서블릿과 JSP의 한계 서블릿으로 개발할 때는 뷰(View)화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다. JSP를 사용한 덕분에 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분에만 자바 코드를 적용했다. 그러나 이러한 형태는 비즈니스 로직과 뷰 영역이 혼재되어 코드를 이해하기 어렵고 유지보수가 힘들어진다는 단점이 있다. MVC 패턴 - 개요 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 변경의 라이프 사이클이 다르기 때문에 유지보수하기 좋지 않다.