본문 바로가기

Memo

저장소 패턴

저장소 패턴은 데이터 저장소를 간단히 추상화한 것으로 이 패턴을 사용하면 모델 계층과 데이터 계층을 분리할 수 있다.

내가 기존에 알기로는 레포지토리 패턴은 데이터 액세스의 추상화를 제공하는 반면, ORM은 객체와 데이터베이스 테이블 간의 매핑을 담당한다고 알고 있는데, 이 둘의 구현 자체도 의존성을 역전시키는 형태로 구현하는 방식에 대해 알게 되었다.

예전에 저장소 패턴이랑 ORM에 대해서 알게되었을때는 어차피 ORM이 영속성을 추상화 하는데 뭐하러 저장소 패턴을 또 쓰지? 뭔가 캡슐화를 통해 유연하게 만들기 위해서 계층을 한번더 만드나 보다~ 라고만 생각하고 넘어 갔었다. 근데 이 책에서 구체적으로 왜 구현하는지 그리고 어떻게 구현하는지가 나와서 이해하는데 많은 도움이 되었다. 
더군다나 저장소 패턴을 사용한다면 ORM을 굳이 쓸필요 없는 경우도 있다고 한다. 물론 반대의 경우도 마찬가지다.
그리고 무엇보다 가장 큰 이점은 테스트를 할때이다. 저장소 패턴을 사용하면 일단 구현한 저장소에대한 테스트를 하고 나면 다른 로직에서는 fake를 만들어서 테스트를 쉽게 할 수 있다.
또한 책에서는 추상화를 대신하는 가짜 객체를 만드는 것은 설계에 대한 피드백을 얻는 아주 좋은 방법이라고 한다. 가짜 객체를 만들기 어렵다면 추상화를 너무 복잡하게 설계했기 때문이라고 한다.

나는 fast api로 프로젝트할때 저장소 패턴이랑 비슷한 crud 계층을 구현했다. 근데 다른 프로젝트들 참고할때 저장소 패턴을 책에서 말한대로 구현한 프로젝트가 있었는데, 그때는 왜 orm을 안쓰고 복잡하게 sql을 구현해서 매핑하는 형태로 구현했을까 라는 궁금증이 있었다. 
근데 지금 보니까 내가 구현한 crud는 단순히 래핑의 형태고 제대로된 추상화는 책에서처럼 orm이 모델에 의존할 수 있도록 해주는게 맞는거 같다. 
또한 계층을 분리했으면 엔드포인트에서 DB 세션을 주입받는 방법도 있겠지만, 애초에 엔드포인트별로 필요한 repository(crud)를 주입하는 형태도 괜찮은거 같다.
이렇게 하면 엔드포인트 로직에서 데이터베이스 로직을 분리할 수 있어서 코드의 가독성과 유지보수성을 향상시킬 수있어 보인다.
근데 만약 복잡한 트랜잭션이 있다면 그냥 db세션을 주입받아서 따로 처리하는게 좋을거 같다.

 

참고 및 출처: <파이썬으로 살펴보는 아키텍처 패턴: TDD, DDD, EDM 적용하기)> (해리 퍼시벌, 밥 그레고리 지음, 오현석 옮김,  한빛미디어 , 2021)

 

'Memo' 카테고리의 다른 글

외부 API 결과에 캐싱 도입  (0) 2023.10.14
서비스 계층과 도메인 서비스  (0) 2023.10.04
React. UseMemo, useCallback, React.Memo  (0) 2022.01.22
TS. 덕타이핑  (0) 2022.01.21
DI? DIP  (0) 2022.01.17