스프링이나 JavaEE 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용하고, 트랜잭션은 보통 서비스 계층에서 시작하므로 서비스 계층이 끝나는 시점에 트랜잭션이 종료되면서 영속성 컨텍스트도 함께 종료된다고 했다.
따라서 조회한 엔티티가 서비스와 리포지토리 계층에서는 영속성 컨텍스트에 관리되면서 영속 상태를 유지하지만 컨트롤러나 뷰 같은 프리젠테이션 계층에서는 준영속 상태가 된다.
//주문 엔티티, 상품을 주문한 회원 엔티티 지연 로딩@Entitypublic class Order{ @Id @GeneratedValue private Long id; @ManyToOne(fetch = FetchType.LAZY) //지연 로딩 전략 private Member member; //주문 회원 ...}
컨테이너 환경의 기본 전략인 트랜잭션 범위의 영속성 컨텍스트 전략을 사용하면 트랜잭션이 없는 프리젠테이션 계층에서 엔티티는 준영속 상태다.
따라서 변경 감지와 지연 로딩이 동작하지 않는다.
class OrderController{ public String view(Long orderId){ Order order = orderService.findOne(orderId); Member member = order.getMember(); member.getName(); //지연 로딩 시 예외 발생 }}
변경 감지 기능은 영속성 컨텍스트가 살아 있는 서비스 계층(트랜잭션 범위)까지만 동작하고 영속성 컨텍스트가 종료된 프리젠테이션 계층에서는 동작하지 않는다.
보통 변경 감지 기능은 서비스 계층에서 비즈니스 로직을 수행하면서 발생한다.
단순히 데이터를 보여주기만 하는 프리젠테이션 계층에서 데이터를 수정할 일은 거의 없다.
오히려 변경 감지 기능이 프리젠테이션 계층에서도 동작하면 애플리케이션 계층이 가지는 책임이 모호해지고 데이터를 어디서 어떻게 변경했는지 프리젠테이션 계층까지 다 찾아야 하므로 애플리케이션을 유지보수하기 어렵다.
비즈니스 로직은 서비스 계층에서 끝내고 프리젠테이션 계층은 데이터를 보여주는 데 집중해야 한다.
따라서 변경 감지 기능이 프리젠테이션 계층에서 동작하지 않는 것은 특별히 문제가 되지 않는다.