프로젝트에 적용한 패턴
이번 프로젝트를 진행하면서 클린 아키텍쳐를 적용하고자 MVVM 을 적용하면서 리포지토리 패턴을 적용하고자 하였다. 솔직히 사용자 입장에서는 어플이 꺼지지 않으면서 잘 작동 되기만 하면 문제는 없겠지만 우린 사용자가 아니고 개발자이기 때문에 이러한 클린 아키텍쳐를 신경을 써서 구현할 이유가 있었기에 부팀장이지만 프로젝트의 전반적인 디자인 패턴을 적용하고자 하였다. 그럼 리포지토리 패턴이 어떤것인지 왜 필요한지 알아보자
Repository 패턴이란?
데이터 출처(로컬 DB인지 API응답인지 등)와 관계 없이 동일 인터페이스로 데이터에 접속할 수 있도록 만드는 것을 Repository 패턴이라고 합니다.
- viewModel 밑에 Repository라는 layer를 하나 더 두어서 viewModel은 오직 비즈니스로직만 집중하게 합니다.
(데이터를 로컬과 서버 중 어디서 가져올지, 또 어떻게 가공할지는 Repostitory가 하기 때문입니다.) 이러한 이유 덕에 지금 프로젝트에 적용되어있는 서버 로직을 변경 할 때 레고에 조립된 블럭 하나만 바꿔주면 되기에 재사용성이 편리하고 레이어가 비지니스 로직이 분리 되어있기 때문에 어떠한 변경에 대응을 할 수있는 디자인 패턴이라고 할 수 있겠다.
- viewModel들간 Repository를 공유해서 데이터 일관성을 유지할 수 있습니다.
그래서 쉽게 내가 이해한걸로 가닥을 잡아보자면 Interface->Imp->ViewModel식으로 로직을 분리를 하여 관리 할 수 있겠고 Imp은 이제 구현체가 되는것이고 이곳에서 Imp 구현체에서 사용할 메소드의 명을 Interface에서 suspend fun으로 선언을 해주어 사용을 하면 되겠다. 또한 Imp에서 구현체가 있기 때문에 viewModel에서는 구현체의 로직을 가지고와서 각각의 UI에 연결만 해준다면 데이터가 변동에 따라 UI는 변동 감지만 해주면 되기 때문에 일일히 초기화를 해줄 필요가 없겠고 관찰자인 observe를 변경되는 데이터가 있는 부분에 달아만 준다면 변동되는 데이터를 감지해서 UI에서 변경을 해줄수 있는것이였다.
실제로 비즈니스 로직을 분리하지 않는다면 UI에서 화면전환이 될때마다 그 데이터에 대한걸 초기화를 해주어야하고 의존성이 너무 강하게 적용하여 데이터 변동 및 서버의 변동에 대한 대응을 하기가 어려워질것이라는 내 주관적인 생각이 든다.
팀 프로젝트에서의 이해도
이러한 패턴 적용 그리고 DI 적용은 클린 아키텍쳐이지만 팀 단위 프로젝트에서는 팀원 모두가 해당 패턴, DI에 학습이 필요하다는 단점이 존재한다. DI 단점이 어떻게 보면 이해하지 않고 사용한 흔적만 봤을때 그 코드의 흐름이 어떻게 적용이 되어있는지 쉽게 알수 없을 뿐더러 이는 리포지토리 패턴에 대한 확실한 이해도가 필요하기 때문에 코드의 의존성이 어떻게 되어있는지 파악하기가 쉽지 않다.
그리고 오래 지속 가능한 프로젝트에 적용을 해야 유지보수가 편하기 때문에 이러한 DI의 적용 및 디자인 패턴의 적용은 필수적이였지만 길면 길고 짧다면 짧은 기간인 한달이였기 때문에 아직 아쉬움이 많은 프로젝트이긴 하지만 Dagger 2 부터 차근차근 공부해 나아갈것이다.