7.0) 스프링 핵심 기술의 응용 스프링의 3개 핵심 기술은 IoC/DI, 서비스 추상화, AOP이다. 스프링의 모든 기술은 객체지향적인 언어의 장점을 적극적으로 활용해서 코드를 작성하도록 도와주는 것이다. 스프링을 사용하는 개발자는 스프링이 제공하는 세 가지 기술을 필요에 따라 스스로 응용할 수 있어야 한다. 이제 세 가지 기술을 애플리케이션 개발에 활용해서 새로운 기능을 만들어보고 이를 통해 스프링의 개발철학과 추구하는 가치, 스프링 사용자에게 요구되는 게 무엇인지를 살펴보자
6.8) 트랜잭션 지원 테스트 선언적 트랜잭션과 트랜잭션 전파 속성 트랜잭션을 정의할 때 지정할 수 있는 트랜잭션 전파 속성은 매우 유용한 개념이다. REQUIRED로 전파 속성을 지정해줄 경우, 앞에서 진행 중인 트랜잭션이 있으면 참여하고 없으면 자동으로 새로운 트랜잭션을 시작해준다. 스프링은 트랜잭션 전파 속성을 선언적으로 적용할 수 있는 기능을 제공한다. UserService의 add()는 트랜잭션의 속성이 디폴트로 지정되어 있으므로 트랜잭션 전파 방식은 REQUIRED가 된다. 그러므로 독자적인 트랜잭션 단위가 될 수도 있고, 다른 트랜잭션의 일부로 참여할 수도 있다. 이로 인해 만약 다른 메소드가 작업 중간에 사용자 등록을 할 필요가 있을 때 add() 메소드는 독자적인 트랜잭션을 시작하는 대신..
6.7) 애노테이션 트랜잭션 속성과 포인트컷 트랜잭션 애노테이션 가끔 클래스나 메소드에 따라 제각각 속성이 다른, 세밀하게 튜닝된 트랜잭션 속성을 적용해야 한다면? 포인트컷 표현식과 트랜잭션 속성을 이용해 트랜잭션을 일괄적으로 적용하는 방식은 복잡한 트랜잭션 속성이 요구되지 않는 한 대부분의 상황에 잘 들어맞는다. 하지만 세밀하게 튜닝된 트랜잭션 속성을 적용해야 한다면 기본 속성과 다른 경우가 있을 때마다 일일이 포인트컷과 어드바이스를 새로 추가해줘야 하기 때문에 메소드 이름 패턴을 이용해서 일관적으로 트랜잭션 속성을 부여하는 방식은 적합하지 않다. 이런 세밀한 트랜잭션 속성의 제어가 필요한 경우를 위해 스프링은 설정파일에서 패턴으로 분류 가능한 그룹을 만들어서 일관적으로 속성을 부여하는 대신에 직접 타..
6.6) 트랜잭션 속성 트랜잭션 정의 TransactionAdvice의 트랜잭션 경계설정 코드를 다시 살펴보자. 트랜잭션 경계는 트랜잭션 매니저에게 트랜잭션을 가져오는 것과 commit(), rollback() 중의 하나를 호출하는 것으로 설정된다. 트랜잭션을 가져올 때 파라미터로 트랜잭션 매니저에게 전달하는 DefaultTransactionDefinition의 용도를 알아보자. /** * 트랜잭션 어드바이스 */ public class TransactionAdvice implements MethodInterceptor { // 스프링의 어드바이스 인터페이스 구현 PlatformTransactionManager transactionManager; public void setTransactionManage..
6.5) 스프링 AOP 자동 프록시 생성 투명한 부가기능을 적용하는 과정에서 아직 한 가지 해결할 과제가 남아 있다. 타깃 코드는 여전히 깔끔한 채로 남아 있고, 부가기능은 한 번만 만들어 모든 타깃과 메소드에 재사용이 가능하고, 타깃의 적용 메소드를 선정하는 방식도 독립적으로 작성할 수 있도록 분리되어 있다. 하지만 부가기능의 적용이 필요한 타깃 오브젝트마다 거의 비슷한 내용의 ProxyFactoryBean 빈 설정정보를 추가해주어야 한다. 새로운 타깃이 등장했다고 해서 코드를 손댈 필요는 없어졌지만, 설정을 매번 복사하고 target 프로퍼티의 내용을 수정해줘야 한다. 이러한 일은 단순하고 쉬운 작업인 만큼 실수하기도 쉽다. target 프로퍼티를 제외하면 빈 클래스의 종류, 어드바이스, 포인트컷의 ..
6.4) 스프링의 프록시 팩토리 빈 ProxyFactoryBean 스프링은 어떤 해결책을 제시해서 트랜잭션 부가기능을 추가해줄 수 있을까? 스프링은 트랜잭션 기술과 메일 발송 기술에 적용했던 서비스 추상화를 프록시 기술에도 동일하게 적용하고 있다. 그러므로 일관된 방법으로 프록시를 만들 수 있게 도와주는 추상 레이어를 제공한다. 생성된 프록시는 스프링의 빈으로 등록돼야 한다. 스프링은 프록시 오브젝트를 생성해주는 기술을 추상화한 팩토리 빈을 제공해준다. 스프링의 ProxyFactoryBean? 스프링의 ProxyFactoryBean은 프록시를 생성해서 빈 오브젝트로 등록하게 해주는 팩토리 빈이다. 기존에 만들었던 TxProxyFactoryBean과 달리, 순수하게 프록시를 생성하는 작업만을 담당하고 프록..
6.3) 다이내믹 프록시와 팩토리 빈 프록시와 프록시 패턴, 데코레이터 패턴 트랜잭션 경계설정 코드를 비즈니스 로직 코드에서 분리해낼 때 적용했던 기법을 다시 검토해보자. 단순히 확장성을 고려해서 한 가지 기능을 분리한다면 전형적인 전략 패턴을 사용하면 된다. 하지만 전략 패턴으로는 트랜잭션 기능의 구현 내용을 분리해냈을 뿐으로 트랜잭션을 적용한다는 사실은 코드에 그대로 남아 있다. 즉, 구체적인 구현 코드는 제거했을지라도 위임을 통해 기능을 사용하는 코드는 핵심 코드와 함께 남아 있다. 트랜잭션이라는 기능은 사용자 관리 비즈니스 로직과는 성격이 다르기 때문에 아예 그 적용 사실 자체를 밖으로 분리할 수 있으므로 부가기능 전부를 핵심 코드가 담긴 클래스에서 독립시켜 UserServiceTx를 만들고 Us..
6.2) 고립된 단위 테스트 복잡한 의존 관계 속의 테스트 가장 편하고 좋은 테스트 방법은 가능한 한 작은 단위로 쪼개서 테스트하는 것이다. 하지만 작은 단위로 테스트하고 싶어도 그럴 수 없는 경우가 많다. 테스트 대상이 다른 오브젝트와 환경에 의존하고 있다면 작은 단위의 테스트가 주는 장점을 얻기 힘들다. UserService의 경우를 생각해보자. UserService는 간단한 기능만 갖고 있다. 그럼에도 UserService의 구현 클래스들이 동작하려면 세 가지 타입의 의존 오브젝트가 필요하다. 1) UserDao 타입의 오브젝트를 통해 DB와 데이터를 주고 받아야 함 2) MailSender를 구현한 오브젝트를 통해 메일을 발송해야 함 3) 트랜잭션 처리를 위해 PlatformTransactionM..
