OSIV는 언제 사용할까?

김영한님의 JPA책 595p를 읽다가 생각을 정리한 글.

 

전통적 OSIV에서는 컨트롤러에서도 변경감지 기능이 동작해서 별로라고 한다. 책에서는 OSIV(요청당 트랜잭션)를 활성화 시켜 엔티티가 컨트롤러까지 존재하고 컨트롤러에서도 트랜잭션, 영속성 컨텍스트가 살아있는 상황을 얘기하고 있다. 여기서 엔티티인 고객 이름을 단순히 뷰에 노출할 때만 다른 이름으로변경하고 싶은 상황을 설명하고 있음. 이때 set()을 호출하면 변경감지가 동작해서 뷰에서 보여줄 때만 다른 이름으로 변경하고 싶은 것인데 DB까지 바뀌니까 좋지 않다고 한다.

 

내 생각.

처음에는 그냥 OSIV를 키고 이름을 상황에 따라 다르게 보여줘야하면 다른 객체 만들어서 매핑, 이름 바꾸고 그걸 반환하면 되잖아… 라고 생각했다. 근데 그러면 굳이 OSIV를 사용해서 엔티티를 컨트롤러까지 끌어올린 이유가 없다. 객체만들고 매핑, 이름변환을 하는 작업이 DTO를 사용하는 방식과 똑같기 때문이다. 어짜피 컨트롤러에서 entity-DTO변환할 것이라면 기존에 하던대로 서비스 레이어에서 entity-dto변환해서 컨트롤러에서는 DTO받아 사용하면 된다. 굳이 OSIV를 켜고 엔티티를 컨트롤러까지 올릴 필요가 없다.

물론 OSIV를 켜고 위와 같은 상황에서만 DTO를 만들어 맵핑하면 변경이 필요한 컨트롤러 메소드에서만 entity-dto변환하고 나머지 컨트롤러 메소드에서는 엔티티를 그대로 사용한다면 생산성이 좀 더 올라가기는 한다.

하지만 API설계상 엔티티를 그대로 반환하지를 못하기 때문에(반환하면 안됨..) OSIV는 사용할 필요가 없는 것 같다.

 

컨트롤러에서 지연로딩이 안되는 문제는 서비스레이어에서 DTO로 변환해서 넘겨주면 서비스 메소드에서 자연스레 DTO매핑시 엔티티의 getter를 호출해서 다 해결되는 문제임. 그리고 엔티티가 아니라 DTO를 반환하기 때문에 지연로딩을 고려할 것도 없다. 괜히 다들 귀찮게 DTO로 매핑해서 쓰고 있는게 아니었다. 모든 것이 고려된 설계였던듯...

 

실제로 현업 개발자 몇명에게 물어보았을 때도 OSIV는 거의 사용하지 않고 않을 것이라고 답변받았다.

결론 : 아직은 OSIV를 사용할 때는 아닌 것 같다.