함께 자라기

이전 글 : [토비의 스프링] 6. AOP (1) 지금까지 해왔던 작업은 비즈니스 로직에 반복적으로 등장하는 트랜잭션 코드를 투명하게 분리해내는 것이었다. 투명하다는 것은 투명한 유리를 사이에 둔 것처럼, 부가기능을 적용한 후에도 기존 설계와 코드에는 영향을 주지 않고 메소드가 호출되는 과정에 다이내믹하게 참여해서 부가적인 기능을 제공해주도록 만들었다는 것이다. 자동 프록시 생성 자동 프록시 생성 빈 후처리기 투명한 부가기능을 적용하는 과정에서 발견됐던 거의 대부분의 문제는 제거했다. 타깃 코드는 깔끔하고, 부가기능은 한 번만 만들어 모든 타깃과 메소드에 재사용이 가능하고, 타깃의 적용 메소드를 선정하는 방식도 독립적으로 작성할 수 있도록 분리되어 있다. 하지만 아직 한 가지 해결할 과제가 남아 있다. ..

AOP AOP는 IoC/DI, 서비스 추상화와 더불어 스프링의 3대 기반기술의 하나다. AOP를 바르게 이용하려면 OOP를 대체하려고 하는 것처럼 보이는 AOP라는 이름 뒤에 감춰진, 그 필연적인 등장배경과 스프링이 그것을 도입한 이유, 그 적용을 통해 얻을 수 있는 장점이 무엇인지에 대한 충분한 이해가 필요하다. 스프링에 적용된 가장 인기 있는 AOP의 적용 대상은 바로 선언적 트랜잭션 기능이다. 트랜잭션 코드를 메소드로 분리 5장의 서비스 추상화 기법을 적용해 스프링이 제공하는 깔끔한 트랜잭션 인터페이스를 썼음에도, 비즈니스 로직이 주인이어야 할 메소드 안에 이름도 길고 무시무시하게 생긴 트랜잭션 코드가 더 많은 자리를 차지하고 있다. public void upgradeLevels() throws E..

Entity의 기본 생성자 JPA를 처음 접한지 얼마 지나지 않았던 시기에, Entity의 기본 생성자와 관련하여 발생한 프록시 예외로 몇 시간 동안 이유를 알아내지 못해 당황해했던 기억이 있습니다. 실제로 JPA 2.0 표준 스펙에 다음과 같은 내용이 있는데요. 엔티티는 반드시 파라미터가 없는 생성자가 있어야 하고, 이는 public 또는 protected 여야 한다. 이와 관련하여 이번 포스팅에서는 JPA Entity의 기본생성자에 대해 간단하게 정리해 보겠습니다. 기본생성자는 필수! JPA를 처음 접하시는 분들이 쉽게 마주하시는 예외가 바로 기본생성자가 없다고 하는 예외인데요. 다음과 같이 엔티티를 만들어 간단한 애플리케이션을 만들어 보았습니다. (Lombok을 사용하였습니다.) @Getter @E..