proxy 3

DI - strategy pattern, decorator pattern, proxy pattern & AOP

DI 의 끝을 모르겠다 ... DI (Dependency Injection) 는 STRATEGY PATTERN(전략 패턴) 이다.. 스프링 프레임워크의 모든 것의 중심엔 언제나 DI가 있다. DI는 확장 포인트 임과 동시에 DI에 또 다른 패턴을 적용함으로써 동적으로 특정 행동을 추가할 수 도 있고, 변경할 수도 있다. 데코레이터 패턴을 잠깐 생각해보자.. InputStream is = new BufferedReaderInputStream(new FileInputStream()); 이는 일종의 생성자를 이용한 DI라고 이해하면 된다. 생성자를 이용한 DI를 통해 특정 기능을 동적으로 추가해주고 있는 것이다. 프록시 를 살펴보자. class HelloProxy{ Hello hello; public void..

@Cacheable, @CacheEvict

빈번하게 호출돼서 화면에 출력돼야 하는 데이터는 Caching 을 이용하면, 속도가 훨씬 빨라진다.. 아주 간단히 말해, 매번 똑같은 데이터를 굳이 새롭게 호출해야 할 필요 없이 특정 영역에 저장해뒀다가 바로 꺼내쓰는 것이 바로 Caching이다. 스프링에선 역시 Caching을 아주 멋들어지 제공한다. 캐싱 기능을 적용하고 싶은 메소드에 @Cacheable 에노테이션만 붙여주면 이 메소드는 캐싱기능이 적용된다.. @Cacheable 은 여러모로 @Transactional 과 흡사하다.. Manager를 등록해야하는것 마저 동일하다 @Transactional 이 transactionManager를 등록해야하는것과 마찬가지로 @Cacheable 은 cacheManager를 등록해야한다.. @Cacheabl..

프록시를 만들기가 번거로운 이유는 무엇일까?

1. 타깃의 인터페이스를 구현하고 위임하는 코드를 작성하기가 번거롭다는 점이다. 부가기능이 필요없는 메소드도 구현해서 타깃으로 위임하는 코드를 일일이 만들어줘야한다. 복잡하진 않지만 인터페이스의 메소드가 많아지고 다양해지면 상당히 부담스러운 작업이 될 것이다. 또, 타깃 인터페이스의 메소드가 추가되거나 변경될 때마다 함께 수정해줘야 한다는 부담도 있다. 2. 부가기능 코드가 중복될 가능성이 많다는 점이다. 트랜잭션은 DB를 사용하는 대부분의 로직에 적용될 필요가 있다. 아직까지 add()메소드에는 트랜잭션 부가기능을 적용하지 않았지만, 사용자를 추가하는 과정에서 다른 작업이 함께 진행돼야 한다면 add() 메소드에도 트랜잭션 경계설정 부가기능이 적용돼야 한다. 메소드가 많아지고 트랜잭션 적용의 비율이 높..