프록시 개념을 사용한 프록시 패턴에 이어서.. 똑같이 프록시 개념을 사용하는 데코레이터 패턴에 대해 알아 보자... 데코레이터 패턴은 프록시 개념 중, 부가 기능을 추가한다는 의도를 담고있는 패턴이다. 역시 예제를 통해 알아보자.. 똑같이 프록시 개념을 사용하므로.. 프록시 패턴과 구조는 동일하다.. (프록시 체인 개념도 함께 알아보자.) 위는 각각 클래스 의존관계와 런타임 객체 의존 관계이다. 프록시는 TimeDecorator, MessageDecorator 두개이며.. 실제 Target 객체는 RealComponent 클래스이다. Componet는... 부가기능을 수행할 MessageDecorator 클래스, TimeDecorator 클래스와 실제 객체인 RealComponent의 인터페이스이다. 실..

이전 포스팅에서.. 프록시의 개념에 대해 알아봤고.. 프록시를 사용하는 의도에 따라 구분되는 두가지 패턴중.. (프록시 패턴, 데코레이터 페턴) 프록시 패턴에 대해 알아보자.. 프록시 패턴은 접근 제어에 초점을 맞추어 사용되는 프록시 개념을 도입한 패턴이다. 예제를 통해 알아보자.. Client(ProxyPatternClient)가 Subject 인터페이스를 의존하고 있다. Proxy(CacheProxy)에 해당하는 구체와 Server(RealSubject)에 해당하는 구체가 동일한 인터페이스(Subject)를 구현하고 있다. 위는 런타임 의존 관계를 표현한 클래스 다이어그램이다. 실제 코드로 알아보자 프록시와 서버가 구현해야할 인터페이스이다. 위는 Subject 인터페이스를 구현한 실제 객체에 해당한다..

템플릿 메서드 패턴, 전략 패턴(템플릿 콜백 패턴) 에서는.. 사실.. 변하지 않는 부분과 변하는 부분으로 나누어서 패턴을 사용하지 않을 때 보다는.. 더 적은 코드로 따로 따로 분리 하여 코드 관리가 가능 했지만, 결국.. 변하는 코드를 적용하기 위한 모든 클래스에 최소 최초에는 원본 코드를 건드려야한다. -> 개발자의 부담으로 다가온다... 원본 코드도 건드리지 않고 변하는 부분에 해당하는 코드를 적용하도록 해보자.. 이를 위해 프록시 개념에 대해 알아보자.. 위 그림에서는 Client가 Server를 직접 호출 하고 있다. 반면, 위 그림에서는 중간에 Proxy라는게 있어서 Client는 Server를 간접 호출하고 있는 상황이다. 이때, 간접 호출할 수 있도록 도와주는 대리자 계층을 프록시라고 부..

지난 포스팅에서는 템플릿 메서드 패턴에 대해 알아봤다. 이번엔 전략 패턴에 대해 알아보자. (이를 템플릿 콜백 패턴이라 부르기도 한다.) 전략 패턴을 템플릿 메서드 패턴과 비교하여 알아보자. 공통점은, 변하는 부분과 변하지 않는 부분을 분리 하는데 초점이 맞춰져있다는 것에 있다. 차이점은.. 분리할때 상속이 아닌 위임으로 문제를 해결한다. 클래스 다이어그램으로 알아보자.. Client는 Context라는 클래스를 참조한다. Context는 Strategy라는 인터페이스를 참조한다. Context는 Strategy를 필드로 가지고 있다. (의존관계 주입) -> 선조립(생성 시점에 전략이 정해짐), 후실행 Context의 execute 메서드는 변하지 않는 부분에 해당한다. (템플릿) Strategy의 ca..

스프링에서 자주 쓰이는 디자인 패턴 중... 템플릿 메서드 패턴에 대해 알아보자.. 템플릿 메서드 패턴은.. 핵심 기능(변하는 부분)과 부가 기능(변하지 않는 부분)을 분리하는데 초첨이 맞춰져 있다. 예를 들면.. 다양한 로직을 처리하는 메서드들의 시작과 끝 시간을 측정하여 걸리는 시간을 측정하는 로그를 남기는 것을 개발하려고 할때.. 시간 측정은 변하지 않는 부분이고..(메서드 별로 로직이 다르지 않음) 해당 메서드의 기존 구현 로직은 변하는 부분이다.(메서드 별로 로직 다름) 클래스 다이어그램으로 알아보자.. Client 클래스는 AbstractTemplate라는 추상 클래스를 참조하고.. execute 메서드를 호출한다. AbstractTemplate는 ClassA, ClassB로 구현된다. 여기서..

트랜잭션이 둘 이상 있을 경우 어떻게 동작 할까? (트랜잭션 내부에서 트랜잭션이 또 적용되면?) 트랜잭션 전파(Transaction Propagation)에 대하여 학습해보자.. 기본 대원칙 1. 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다. 2. 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다. 기본 대원칙에 대해 자세히 알아보자. 물리 트랜잭션, 논리 트랜잭션 위 그림 처럼, 클라이언트가 어떤 로직1을 호출 하면 트랜잭션이 수행되고 로직1은 로직2를 호출하여 트랜잭션이 또 한번 수행된다고 생각 해보자. 스프링은 첫번째 두번째 트랜잭션을 논리 트랜잭션, 두개를 묶어 물리 트랜잭션이라 개념을 만들었다. 물리 트랜잭션 물리 트랜잭션은 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다...

트랜잭션 내부 로직 수행도중... 예외가 터지면 어떻게 될까..? 예외가 발생할 경우의 트랜잭션 처리에 대해 알아보자.. 앞선 @Controller, @Service, @Repository 포스팅에서 잠시 알아보긴 했었다.. https://starryeye.tistory.com/97 더 자세하게 알아보자.. 스프링 트랜잭션 AOP는 예외 종류에 따라 트랜잭션을 커밋하거나 롤백한다. Java의 예외 이전 포스팅 https://starryeye.tistory.com/52 참조 언체크 예외(RuntimeException, Error와 그 하위 예외) -> 트랜잭션 롤백 체크 예외(Exception과 그 하위 예외) -> 트랜잭션 커밋 스프링은 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용하고, 언체크 ..

트랜잭션의 옵션 value 요소, transactionManager 요소 트랜잭션 매니저를 둘 이상 사용할 경우에 사용된다. 트랜잭션 프록시가 사용할 트랜잭션 매니저를 지정해 줄 수 있다. 트랜잭션 매니저의 스프링 빈 이름을 기입하면 된다. 생략 가능하며, 생략할 경우 기본으로 등록된 트랜잭션 매니저가 사용된다. ex. @Transaction("TxM") (어노테이션에서 요소가 하나인 경우, value는 생략가능) rollbackFor 요소 스프링 트랜잭션은... 언체크 예외가 발생하면 롤백하고, 체크 예외가 발생하면 커밋한다. 하지만.. 커밋하고 싶지 않은 체크예외가 있을 수 있다. 이 때 사용된다. ex. @Transaction(rollbackFor = Exception.class) -> 모든 예외를..