리파지토리 패턴에 대해 아시나요?
리파지토리 패턴(Repository Pattern)에 대해 아시나요? 이번에 소개해드릴 두 개의 글은 리파지토리 패턴에 대한 글입니다.
먼저 첫 번째 글을 소개합니다.
리파지토리 패턴은 데이터를 영속적으로 유지해주는 문제를 추상화합니다.
“The Repository pattern is an abstraction over persistent storage. It hides the boring details of data access by pretending that all of our data is in memory.” (Architecture Patterns with Python, chapter 2)
예를 들어, 아래와 같은 API 요청이 있을 때,
fetch('/store', {
// ...
body: JSON.stringify({
// ... data
}),
});
아래와 같이 추상화합니다.
// 정의
const StoreRepository = {
create(...data) {
fetch('/store', {
// ...
body: JSON.stringify({
// ... data
}),
});
}
};
// 호출부
// fetch를 직접 호출하는 대신 메서드 호출
StoreRepository.create({ ... });
추상화를 했다는 건, 같은 인터페이스를 가진 다른 구현체로 바꿀 수 있다는 걸 의미하기도 합니다. 그리고 추상화 전과 달리 세부 구현을 숨기는 캡슐화도 되기 때문에 변경이 발생했을 때 대응이 수월합니다. 물론 구현체가 중복해서 존재하는 경우 중복 제거도 가능합니다.
다른 구현체로 바꿀 수 있다는 건 테스트도 전과 달리 더 수월하게 할 수 있다는 걸 의미합니다. 그래서 아래와 같은 장점이 있습니다.
하지만 추상화를 통해 데이터 계층이 추가되면
데이터를 사용하는 곳과 리파지토리 계층 간의 데이터 구조 매핑이 필요합니다. 즉, 장점으로 가져온 유지보수성 향상을 깎아먹게 됩니다. 그래서 결국 득인지 실인지는 따져봐야겠습니다.
계층이 늘어나면 코드를 살펴볼 때 복잡성이 올라갑니다.
프론트엔드 개발을 하면서 리파지토리 패턴은 익숙하지 않을 수 있습니다. 그리고 당장 필요하지 않을 수도 있습니다. 하지만 복잡한 애플리케이션을 개발 해야 할 일이 생길 때, API 호출에 사용하는 라이브러리를 교체해야 할 때 등 리파지토리 패턴이 필요한 순간에 생각이 난다면 충분하지 않을까 합니다.
프론트엔드에서 리파지토리 패턴을 사용하는 것, API 요청을 추상화 하는 것과 관련해선 제가 쓴 글도 있으니 필요하시면 참고하셔도 좋을 거 같습니다.
그리고 마지막으로 소개해드리는 글은 '리파지토리는 안티 패턴인가?'라는 주제의 글입니다. 글의 분량도 그렇고 내용도 읽기 수월하진 않을 정도로 어렵기도 합니다. 하지만 기존에 잘 활용되고 있는 패턴에 대해 다시 한 번 돌아보게 하는 글은 옳고 그름을 떠나 한 번쯤 읽어볼만 하다고 생각합니다.
저도 필요할 때 몇 번은 더 읽어봐야 할 거 같습니다 :)
리파지토리 패턴과 무관하지만 이 글에서 의미있는 문장이 있는거 같아 인용합니다.
Developers are really stubborn people. To become a software engineer, you should have a mindset of “everything is possible” guy. When something is not working the way we want it, we would just put more effort into it. The more effort we invest, the harder it is to let it go.
You know, how they said: habits prevent any progress. (습관은 진전(또는 개선)을 방해합니다.)
