seo92iy

ProxyFactoryBean MethodInvocation은 일종의 콜백 오브젝트. proceed()를 실행하면 타깃 오브젝트의 메소드를 내부적으로 실행한다. MethodInvocation 구현 클래스는 일종의 공유 가능한 템플릿 처럼 동작한다. ProxyFactoryBean은 작은 단위의 템플릿/콜백 구조를 응용해서 적용했기 때문에 템플릿 역할을 하는 MethodInvcation을 싱글톤으로 두고 공유할 수 있다. 메소드를 선정해서 트랜잭션을 적용할 수 없다. MethodInterceptor 오브젝트를 여러 프록시가 공유해서 사용하기 위해서 타깃 정보를 가지고 있지 않다. MethodInterceptor를 싱글톤 빈으로 등록할 수 있는 건데 여기다가 특정 프록시에만 적용되는 패턴을 넣으면 문제가 된다..

일반적으로 사용하는 프록시 클라이언트와 사용 대상 사이에 대리 역할을 맡은 오브젝트를 두는 방법 디자인 패턴에서 프록시 패턴 그 중 타깃에 대한 접근 방법을 제어하려는 목적을 가진 경우 타깃의 기능을 확장하거나 추가하지 않음. 보통 타깃 오브젝트를 생성하기 복잡하거나 당장 필요하지 않으면 미리 생성하지 않는데 레퍼런스가 미리 필요한 상황이 있다. 이때 프록시 패턴을 사용한다. 접근 권한을 제어하기 위해 사용할 수도 있다. 다이내믹 프록시 프록시 클래스를 정의하지 않고도 API를 이요해서 프록시처럼 동작하는 오브젝트를 다이내믹하게 생성 리플렉션 기능을 이용해서 프록시를 만든다. 인터페이스의 메소드가 많이 늘어나도 invoke에서 다 처리하니까 편하다. TransactionHandler와 다이내믹 프록시를 ..

프록시 자신이 클라이언트가 사용하려고 하는 실제 대상인 것 처럼 위장해서 클라이언트의 요청을 받아주는 것. 타깃 targer / 실체 real subject 프록시를 통해 최종적으로 요청을 위임받아 처리하는 실제 오브젝트 1. 클라이언트가 타깃에게 접근하는 방법 제어 2. 타깃에게 부가적인 기능을 부여 - 데코레이터 패턴 여러개의 프록시를 사용할 수 있고 여러개인 만큼 순서를 정해서 단계적으로 위임하는 구조로 만들면 된다. 데코레이터의 다음 위임 대상은 인터페이스로 선언하고 생성자나 수정자를 통해 위임 대상을 외부에서 런타임 시에 주입 받음.

트랜잭션 기능에 많이 사용 비지니스 로직에서 트랜잭션 부분 분리 메소드 분리 -> DI 이용 클래스 분리 하나의 인터페이스에 클래스 2개 -> 같은 인터페이스 타입을 가진 빈이 2개가 되면 @Autowired에 문제가 생긴다. 1. 타입 검색 2. 이름 검색 따라서 UserService 인터페이스 타입을 가진 UserServiceTx, UserServiceImpl 중에 아이디가 userService인 빈이 주입된다.(ApplicationContext.xml에서 설정한대로 UserServiceTx가 주입됨) 남은 하나를 더 가져와야 하므로 @Autowired UserServiceImpl userServiceImpl; 로 한번 더 설정해준다. 장점 : 비즈니스 로직 클래스에서 트랜잭션 부분 분리. 비즈니스 ..

portable Service Abstraction 추상화 우리는 Controller 로 코딩을 했지만 아래에서는 Servlet 기반으로 동작한다. 우리가 조금 더 편하게 코딩하기 위함. 기술이 바뀌더라도 코드에 변함이 없다. MVC model view controller 스프링 트랜잭션 AllorNothing @Transactional 애노테이션을 붙이면 그 메소드는 트랜잭션 처리가 된다. setAutoCommit(false); ~ commit/rollback() 이걸 안해도 된다. JPA JDBC 하이버네이트 다 쓸 수 있으니까 PSA 스프링 캐시 @Cacheable

애노테이션 - 주석이랑 비슷하다. LogExecutionTime 애노테이션 생성 @Target(ElementType.METHOD) - 이 애노테이션을 어디서 쓸 수 있는지 @Retention(RetentionPolicy.RUNTIME) - 애노테이션 정보를 언제까지 유지할 것인가 LogAspect 클래스 @Component - bean으로 등록되어야 하기 때문에 사용 @Aspect joinPoint -> 애노테이션이 붙은 타겟(여기서는 매소드들)

AOP Aspect of Programming 흩어진 코드를 한 곳으로 모은다. @Transactional AOP가 사용하는 애노테이션 1. 컴파일 A.java -------(AOP)------> A.class (AspectJ) 2. 바이트코드 조작 A.java -> A.class ----(AOP)------->메모리 (AspectJ) A클래스를 클래스로더가 읽어올때, 메모리에 올릴때 조작 3. 프록시 패턴 (스프링 AOP) 디자인 패턴 중 하나를 사용해서 AOP와 같은 효과를 내는 방법

1. 클래스에 생성자가 1개 뿐이고 생성자로 주입받는 래퍼런스 변수들이 bean으로 등록되어 있다면 그 bean을 자동으로 주입해주도록 제공한다. @Autowired 생략가능 (스프링 4.3 이상 제공) 2. field로 주입받을 땐 애노테이션 붙이기. 3. setter에 애노테이션 붙이는 방법도 있음. IoC 컨테이너가 setter를 통해서 bean을 찾아서 넣어줌. 스프링 래퍼런스에서 권장하는 방법은 1번. 필수적으로 사용해야하는 래퍼런스 없이는 인스턴스를 만들지 못하도록 강제해두었기 때문. 실수가 줄어듦. 순환참조 발생 가능성이 있음. -> 2번, 3번으로 해결. (이건 더 공부) 1,3번 할때는 final 선언 안된다. 2번은 된다. final 선언하는 이유는 한번 받은 다음 다른 걸로 바뀌지 않..