토비의 스프링 정리 썸네일형 리스트형 토비의 스프링 - 6.9 6장 정리 6.9.1 정리 트랜잭션 경계설정 코드를 분리해서 별도의 클래스로 만들고, 비즈니스 로직 클래스와 동일한 인터페이스를 구현하면 DI의 확장 기능을 이용해 트랜잭션 부가기능을 만들 수 있음 트랜잭션처럼 환경과 외부 리소스에 영향을 받는 코드를 분리하면 비즈니스 로직에만 충실한 테스트를 만들 수 있음 목 오브젝트를 이용하면 쉽게 고립된 테스트를 만들 수 있음 DI를 이용한 트랜잭션 분리는 데코레이터 패턴과 프록시 패턴으로 이해될 수 있음 번거로운 프록시 클래스 작성은 JDK 다이내믹 프록시를 이용하면 간단히 만들 수 있음 다이내믹 프록시는 스태틱 팩토리 메소드를 사용하기 때문에 빈 등록하기 번거로움. 팩토리 빈을 사용하면 되고, 스프링은 자동 프록시 생성 기술에 대한 추상화 서비스를 제공하는 프록시 팩토리 .. 더보기 토비의 스프링 - 6.8 트랜잭션 지원 테스트 6.8.1 선언적 트랜잭션과 트랜잭션 전파 속성 REQUIRED로 전파 속성을 설정하면 앞에서 트랜잭션이 진행되고 있으면 새로운 트랜잭션을 시작하지 않고, 기존의 트랜잭션에 참여를 함 REQUIRED 전파 속성을 가진 메소드를 결합해 다양한 크기의 트랜잭션 작업을 만들 수 있음 A 메소드에서 B 메소드를 호출하는데, A와 B 작업이 모두 완료되어야만할 때, REQUIRED 전파 속성을 사용해야 함 AOP를 이용해 코드 외부에서 트랜잭션 기능을 부여해주는 방법을 선언적 트랜잭션(Declarative Transaction)이라 함 대조적으로, TransactionTemplate나 개별 데이터 트랜잭션 API를 사용해 직접 코드 안에서 사용하는 방법을 프로그램에 의한 트랜잭션(Programmatic Trans.. 더보기 토비의 스프링 - 6.7 애노테이션 트랜잭션 속성과 포인트컷 6.7.1 트랜잭션 애노테이션 포인트컷과 트랜잭션 속성을 이용해 트랜잭션을 일괄적으로 적용하는 방식은 대부분 상황에서 잘 들어맞음 하지만, 세밀하게 튜닝된 트랜잭션 속성의 경우 포인트컷과 트랜잭션 속성 사용으로는 적합하지 않음 포인트컷과 트랜잭션 속성과 같이 설정 파일에서 분류 가능한 그룹으로 만들어 일괄적으로 속성을 부여하는 대신, 직접 타킷에 속성정보를 가진 애노테이션을 지정해 세밀하게 트랜잭션 속성을 적용함 이 애노테이션을 트랜잭션 애노테이션이라 함 @Transaction 애노테이션을 정의한 코드 @Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documented public .. 더보기 토비의 스프링 - 6.6 트랜잭션 속성 6.6.1 트랜잭션 속성 트랜잭션 추상화를 할 때 그냥 넘어간 것이 한 가지 있음 트랜잭션 속성을 담당하는 DefaultTransactionDefinition 오브젝트임 트랜잭션 경계는 트랜잭션 매니저에서 트랜잭션을 가져오는 것과 commit(), rollback() 중 하나를 호출하는 것으로 설정됨 public Object invoke(MethodInvocation invocation) throws Throwable { TransactionStatus status = this.transactionManager.getTransaction( new DefaultTransactionDefinition()); try{ Object ret = invocation.proceed(); this.transaction.. 더보기 토비의 스프링 - 6.5 스프링의 AOP 6.5.1 프록시 생성의 문제 부가기능이 타깃 오브젝트마다 새로 만들어지는 문제는 ProxyFactoryBean의 어드바이스를 통해 해결 되었음 남은 문제는 부가기능의 적용이 필요한 타깃 오브젝트마다 비슷한 내용의 ProxyFactoryBean 빈 설정정보(XML)를 추가해야하는 부분임 빈 후처리기를 사용하면 설정정보를 자동으로 추가할 수 있음 6.5.2 빈 후처리기를 이용한 자동 프록시 생성기 스프링은 컨테이너로서 제공하는 기능 중에서 변하지 않는 핵심적인 부분외에 대부분 확장할 수 있도록 확장 포인트를 제공하고 있음 관심을 가질만한 확장 포인트는 BeanPostProcessor 인터페이스를 구현해서 만드는 빈 후처리기임 스프링은 빈 후 처리기가 빈으로 등록되어 있으면 빈 오브젝트가 생성될 때 마다 빈.. 더보기 토비의 스프링 - 6.4 스프링의 프록시 팩토리 빈 6.4.1 ProxyFactoryBean 스프링에서 제공하는 깔끔한 부가기능 추가를 위한 클래스 JDK에서 제공하는 다이내믹 프록시 단점 해결 서비스 추상화와 동일하게 스프링은 일관된 방법으로 프록시를 만들 수 있는 추상 레이어임 스프링의 ProxyFactoryBean는 프록시를 생성해서 빈 오브젝트로 등록하게 하는 팩토리 빈임 ProxyFactoryBean는 순수하게 프록시 생성 작업만 담당하기 때문에, 부가기능은 어드바이스라 불리면서 MethodInterceptor를 구현한 별도의 빈에 둘 수있음 즉, ProxyFactoryBean가 생성하는 프록시의 부가기능은 MethodInterceptor를 구현해서 만듦 MethodInterceptor는 InvocationHandler와 비슷하지만 두 가지 다른.. 더보기 토비의 스프링 - 6.3 다이내믹 프록시와 팩토리 빈 6.3.1 프록시 전략 패턴 적용을 통한 부가기능 구현의 분리 부가적 기능을 위임을 통해 분리 기능을 사용하는 코드는 핵심 코드와 함께 남아 있음 부가기능과 핵심기능의 분리 트랜잭션은 비즈니스 로직과 성격이 다르기 때문에 분리 가능 트랜잭션을 UserServiceTx로 분리하여 UserServiceImpl에는 비즈니스 로직만 남음 핵심기능 인터페이스 적용 부가기능과 핵심기능을 같은 인터페이스를 구현하게 만듦 클라이언트는 인터페이스를 통해서만 핵심기능 사용 부가기능 코드를 먼저 거쳐 비즈니스 로직 부분을 핵심기능에 위임함 실제 대상인 것처럼 위장해서 클라이언트의 요청을 받기 때문에 프록시(Proxy)라도 부름 6.3.2 프록시 패턴 설명 부가기능과 핵심기능은 같은 인터페이스를 구현 프록시를 통해 최종적으로.. 더보기 토비의 스프링 - 6.2 고립된 단위 테스트 6.2.1 복잡한 의존관계 속의 테스트 작은 단위로 테스트 할 수록 논리적 오류를 찾기 쉬움 하지만, 다른 오브젝트와 환경에 의존하고 있다면 작은 단위 테스트의 장점을 얻기 힘듦 UserService는 사용자 관리 로직만 갖는 아주 단순한 비즈니스 로직임에도, 세 가지의 의존 관계를 가지고 있음 UserService는 UserDao, TransactionManager, MailSender 의존을 가지고 있음 문제는 세 가지 의존 오브젝트들이 자신의 코드만 실행되지 않음 Jdbc를 이용해 UserDao를 구현한 UserDaoJdbc는 DataSource의 구현 클래스, DB 드라이버, DB 서버까지의 네트워크 통신, DB 테이블 등에 모두 의존함 따라서, UserService를 테스트 하지만 그 뒤의 오브.. 더보기 이전 1 2 3 4 5 6 7 다음
