OSIV는 안티패턴?

OSIV의 단점

OSIV가 안티패턴(🔗)이라고 주장하는 의견이 있어 그 내용을 정리해보면 다음과 같다. 

 

1. UI rendering phase*에서는 서비스 레이어가 명시적으로 트랜잭션을 수행할 일이 없기 때문에 auto commit 모드로 실행되게 되며, 이는 DB 서버에 트랜잭션 로그를 flush 하는 부하를 줄 수 있으므로 connection을 read-only로 설정하여 트랜잭션 로그를 쓰지 않도록 최적화 하는 방법이 있다.
   
   
2. DB statement를 View와 Service 둘 다 생성하게 되므로 레이어 간의 관심사가 분리되지 않게 된다. 쿼리 실행 위치와 타이밍을 예측 하기도 검증하기도 어려워진다는 뜻이다.
   예를 들어 만약 불필요한 statement가 생성되진 않는지 statement 갯수를 assert하는 테스트를 작성하려면 서비스 레이어 단독으로 테스트가 불가능하고 뷰 레이어를 포함시켜야 테스트가 가능하여(뷰 레이어에서도 lazy loading에 의해 statement가 생성되므로). 테스트 시간도 길어진다.
   
   
3. UI rendering phase에도 DB 커넥션을 잡고 있으므로 TPS(Transactions per second)로 측정되는 트랜잭션 처리량 (DB Transaction throughput)이 줄어들 수밖에 없다.

---

*서비스 레이어에서 트랜잭션을 닫고 나면, UI 렌더링 단계에서 첫 트랜잭션 때 가지고 오지 못한 데이터들을 뒤늦게 lazy loading하는 phase가 있는데, 이를 UI rendering phase라고 표현함. 

 

 

OSIV가 안티패턴이라는 의견에 대한 나의 견해
1번은 대안이 있고, 2번은 확실한 문제점으로 보이며, 3번은 그 영향력이 미미할 것으로 보이나 케이스에 따라 측정이 필요할 것으로 보인다. 그러나 그 측정 자체도 무의미할 것처럼 보이는 이유는 이미 Lazy loading을 채택한 경우에 이를 다시 `osiv = false`로 변경하기로 결정하기엔 그 변경이 너무나 복잡하고 번거롭기 때문에 osiv 사용/미사용은 tps가 `trade-off`임을 고려하여 이미 결정된 이후일 것이기 때문이다.

 

댓글에서 누군가 조금은 부족한 논리로나마 '대안이 없는 트집잡기'라는 식으로 반박하였는데, 정확한 표현은 아니나 3번에 대해서 나도 비슷한 생각을 한다. 이미 파리채 대신에 전기 파리채를 들기로 마음 먹은 순간부터 전기사용은 고려가 되어있을 수밖에 없는데("전기" 파리채), 그 부분을 들어 전기 파리채는 전기를 사용한다!라고 말하는 것처럼 들린다.

 

Lazy Loading은 왜 필요한가? OOP를 지향하기 위한 노력의 일환이다. OOP를 위해 DB와 앱 사이에 ORM이라는 추상화를 놓았기 때문에, ORM을 선택한 시점에서 이미 추상화에 따른 어쩔 수 없는 비용은 치르기로 마음먹었다. 이것을 가지고 OSIV가 안티패턴이라고 주장하는 것은 비약일 것이다.