[Share] 5주차 토론 내용

[sojeongw]

Topic

[토비의 스프링] 5장. 서비스 추상화

이번 주는 비교적 토론이 많지는 않았습니다. 가볍게 읽어보세요!

Detail

코드 개선

주만
(코드 개선 시 생각할 항목을 짚어보며) 변경이 어디서 일어날 것 같으며 쉽게 대응할 수 있는가? 이 부분은 한번 당해본 사람만이 알 수 있는 것 같다. 경험적으로 숙련되어야 해결할 수 있을 듯.

테스트만을 위한 UserService 객체 구현

주만
예제를 보면 UserServiceTest에서 테스트용 객체를 따로 만든다. 원래도 이런 방법을 잘 쓰나?

주형
예제의 의도대로 트랜잭션을 중간에 끊기게 하려면 써야할 것 같다.

트랜잭션

주만
예를 들어 ORM을 하나 때리면(..!) 각자 다 커넥션이 생기는 것인가?

주형
예제 상으로는 각자 맺는게 맞는데 하나의 트랜잭션으로 묶이면 메모리상에 쫙 가지고 있다가 리퀘스트를 한번에 쏜다.

주만
커넥션 잡는게 0.2초라고 했을 때, 메소드를 세번 호출하면 3배가 되는 걸로 이해하면 되는가?

주형
커넥션 풀에서 가져다 쓰니까 정확히 3배는 아닐 것 같다. 확실하지 않아서 찾아봐야할 것 같다.
추가로 말하자면 커넥션 풀에 대한 policy를 따로 설정할 수 있다. 누가 쓰고 있을 때 접근하면 기다리게 할지 무조건 읽을지 정하는 것이다.

근원
어차피 락 거니까 왜 커넥션 풀이 여러 개 필요하지? 했는데 주형 말을 들어보니 동시에 접근해도 읽는 것만 허용하는 policy를 설정할 때는 필요해 보인다.

트랜잭션 추상화

주형
예제에서 리팩토링한 코드도 나는 불편하더라. user에 대한것만 해야되는데 커넥션 관련한 코드가 섞여있기 때문이다. 스프링에서는 @Transactional을 쓰면 이런 코드를 줄일 수 있다.

근원
단계적으로 설명하다보니 그런 것 같다. 실제로 AOP 챕터에 가면 또 고치게 된다.

주만
나는 주형과 생각이 다르다. 트랜잭션 경계 설정이 코드의 흐름상 여기에 같이 있어야겠다고 생각했다.

근원
지금은 그렇게 하는게 맞는데 관심사를 정확히 나누면 AOP로 다시 나눌 수 있어서 다음 챕터에 설명이 나온다.

추상화와 DI에 대한 정의

주만
서비스에서 기술을 덜어내는 게 추상화다!
DI는 서로가 서로를 모르는 것이다!

테스트 대역

주만
저번에 들어보니까 모듈마다 샌드박스(test DB)를 두는 게 좋다고 하더라. 리퀘스트를 잘 확인하려면 dummy가 아니라 실제 DB에 날려봐야 확실히 알 수 있기 때문이다. 실제 기능 테스트가 필요한 곳에는 활용하면 좋을듯.

회고

주만
개발을 이렇게 해야 하는 거구나 느낄 수 있었던 장이었다.

[AgwaB]

개발을 이렇게 해야 하는 거구나 느낄 수 있었던 장이었다. 저는 주만님의 이 말이 주옥같네요. 우리 서로 성장하고 있는 것 같아서 기분이 좋습니다.

[joomanzi]

저번 스터디에서 DB 커넥션 관련하여 궁금했던 내용 정리합니다.

Q. 책에서 처럼 매번 Query 마다 커넥션을 생성하는가?
A. DB connection pool에 있는 connection이 있으면 새로 생성하는 것이 아니라 가져다 씀.
Pool에서 유지하는 connection의 수는 설정으로 관리할 수 있음.
책에서와 같이 하나의 커넥션을 사용해 하나의 쿼리가 요청되는 것은 맞지만, 매번 커넥션이 생성되는것은 아님
ref.https://stackoverflow.com/questions/35525574/how-to-use-database-connections-pool-in-sequelize-js

+(민수님 질문) 트랜잭션은 하나의 커넥션에 들어간다.
ref. https://stackoverflow.com/questions/45689060/transaction-control-over-a-connection-pool