티스토리에 있던 예전 글을 이사했습니다.
https://velog.io/@chs98412/Django-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%A0%88%EC%9D%B4%EC%96%B4
위 포스팅에서 장고 어플리케이션 안의 서비스 로직을 분리시키는 과정을 작성했다.
현재 코드에서는 서비스 레이어에서 장고 모델에 접근하여 데이터를 받아오는 과정을 취해주고 있다.
앞선 포스팅에서도 스프링부트의 구조와 비교하여 리팩토링 하였으므로 이번에도 스프링부트 프로젝트의 구조와 장고를 비교해보면서 개선할 점을 찾아보겠다.
스프링부트 프로젝트에서 구조는 다음과 같다.
Comment라는 엔티티에 대하여 CommentRepository (JpaRepository 를 확장한)에 db에 접근하여 정보를 받아오는 기능들이 담겨있다.
또한 CommentService에서 CommentRepository의 기능들을 이용한다.
스프링부트 프로젝트를 진행할 때에는 당연한 것으로 여겼었다. 왜냐면 JpaRepository를 확장하여 사용하는것을 일종의 “지겨캬 하는 규칙”이라고 생각하고 사용했기 때문이다.
하지만 장고는 이와 구조도 다르기 때문에, Repository가 있는 이유와 그 장점에 대해 생각해보고 장고에 적용해보기로 했다.
기능의 분리 서비스를 분리할 때와 마찬가지로 db에 접근하는 기능을 분리시켜서 각 레이어가 하나의 역할만 가지도록 할 수 있다.
추상화 현재 장고 ORM을 이용하여 db에 접근하고 있다. 만약 ORM이 아니라 다른 기술스택을 이용하여 db에 접근하게 된다면 서비스 레이어에 존재하는 db 접근 코드들을 전부 수정해야 한다. 하지만 Repository를 분리하여 db접근 코드를 서비스레이어는 자세히 몰라도 되도록 작성한다면, 다른 기술 스택을 사용하더라도 Repository의 코드만 수정해주면 되기 때문에 Service레이어의 코드를 수정하지 않아도 되고, 변경에 의한 오류를 적게 범할 수 있는 장점이 있다.
현재 서비스 레이어의 코드는 다음과 같다.
위 코드에서 db에 접근하는 코드를 Repository 레이어로 분리시켜 감쌀 예정이다
bookRepository.py
commentRepository.py
위와 같이 Repository 레이어에 기능을 만들어주고 서비스 레이어에서 각 기능을 호출하였다.
서비스 레이어의 코드는 다음과 같이 변경하였다.
이제 장고 ORM이 아니라 다른 기술 스택을 사용하면, 서비스 레이어의 코드는 변경할 필요 없이, bookRepository, commentRepository의 코드만 수정하면 된다.
