ViewModel에서 꼭 Repository를 사용할 필요가 있을까요?

Question

화면을 만들던중 Repository가 꼭 필요한것 같지 않은 상황이 와서 질문드립니다.

혹은 Repository는 사용하되 DB는 사용하지 않아도 되는지 궁금합니다.

상황은 이러합니다.

 

A화면은 B화면에서 만들어진 Detail 리스트를 받아와 나열하는 화면입니다.

즉 A화면은 B화면에서 받은 Detail 리스트가 하나의 아이템이 되어 이 아이템들이 계속해서 나열되는 리스트 화면입니다.

 

이러한 화면 구성에서 B화면에서 리스트를 작성할때, 생각해보니 이 화면은 단순히 A화면으로

만들어진 리스트를 넘겨주기만하면 됩니다. 단순 리스트를 만드는 화면이라 앱을 나갔다 들어와도 DB에서 불러오거나 그렇다할 요소가 없습니다..(아직까지는요)

MVVM 패턴에서 ViewModel은 Respotory를 바라본다고 하나요? Repository를 통해서

데이터를 가져오고 하잖아요? 아이템을 추가해도 ViewModel에서 Repository를 통해서 하구요.

Repository는 웹이나 DB에서 데이터를 가져오구요. 뭐 뷰모델에서 시킨? 아이템 추가같은걸 하겠죠..

 

그런데 위에서 말씀드렸다시피 단순 List를 넘겨주기만 하면 되는 화면이라  굳이 DB같은게 필요한가 싶습니다. 따라서 DB의 존재가 필요가 없으므로 Repository도 필요 없어도 되나요?

아니면 그래도 디자인패턴의 구분을 위해 DB를 사용하지 않더라도 Repository같은 클래스는 작성해주는게 좋나요?

 DB같은것은 아마 A화면에서 최종적으로 사용하지 않을까 싶습니다

Answer 1

B화면에서 어떤 동작을 하고 있는지가 중요합니다. B화면이 데이터소스(DB나 메모리)와 무언가를 주고 받아서 데이터소스에 변경이 가해진다면, 당연히 데이터소스에서 데이터를 가져와야 합니다.

Repository의 역할은 비지니스 로직, 또는 데이터의 핸들링입니다. 뷰모델에 이런 기능이 있다면 여기로 옮기는 것이 좋습니다. 만약 그렇지 않다면 Repository를 생략해도 될듯합니다. 어떤 개발자들은 코드의 일관성을 위해 무조건 Repository를  두라고 하지만, 그건 상황에 따라 결정되어야 한다고 생각합니다. 불필요한 쓸모없는 클래스라면 사용하지 않는 것이 맞습니다. 괜히 코드만 증가시키니까요.

따라서 Repository가 불필요하다고 판단되면, 사용하지 않으시면 됩니다. 그리고 추후에 필요해지면 추가하시구요. 그런데, 이게 팀 프로젝트라면 팀원들과의 상의 후에 결정에 따르는 것이 제일 우선입니다.

Comments

참고로 B화면에서 데이터 소스와 어떤 interaction이 일어나지 않는다고 하신 걸 보면, 단순히 데이터를 입력화는 Form으로 보이는데, 그 화면에서 저장이나 확인 버튼을 누르면 A에서 B의 입력값을 받아서 저장을 하는 구조인거요?

제말이 맞다면, 두가지 방법으로 해당 동작을 구성할 수 있을 듯 합니다.
하나는 현재 하신 방법대로  B에서 입력을 받아서 A에서 저장,
다른 방법은 B에서 입력과 저장 처리. A에서는 데이터 소스에서 데이터를 다시 가져옴.

그런데, 잘 생각해보시면 첫번째든 두번째든, 입력값에 대한 검증(validation)이 필요할 것 같아 보이는데. 그렇다라면, 이건 비지니스 로직에 해당합니다.
그리고 저장이 실패했을 경우, 재시도를 하게 한다면, B에서 저장까지 처리하는게 맞을 것 같습니다.

---

사실 질문하기위해 A,B 두화면만 말씀드렸는데 좀 더 정확하고 상세하게 설명드리면 사실은 A,B,C화면으로 구성되어있고,
A화면은 C화면에서 작성한 정보(데이터 - 리스트)를 단순 보여주는 화면이고
B화면은 C화면에서 무엇을 토대로 작성되는지 타이틀 옵션같은 것을 선택하는 화면입니다. 즉 A에서 버튼을 클릭 -> B화면으로 이동 -> 타이틀 옵션 선택 -> 이정보를 C로 보내면서 C화면으로 이동 -> 이 옵션에 대한 상세 정보화면 작성(리스트) -> 저장or 완료버튼 -> A화면에 C화면의 데이터 전달 -> A화면에서display(나열) -> 과정 반복 -> A화면 저장 클릭 -> DB 최종(?) 저장
이정도로 생각하고 있습니다.

이제다시 위의 B화면(옵션 타이틀선택화면)은 생략하고..

이전에 A화면은 멀티타입 리사이클러뷰를 사용해서 작성하던 루틴 작성페이지입니다.
그런데 각 아이템 마다 Detail한 옵션같은것을 세세하게 추가하기 위해서는 하나의 뷰(A화면) 내에서 다 처리하려고하니 너무 복잡(뷰이든 데이터로직이든)해질 것같아서, 이것을 B화면 내에서 처리하려고 노선을 조금 틀었습니다.

이렇게하면 B화면은 멀티타입 리사이클러뷰를 사용할 필요도 없어지고, 단순 싱글 타입 리사이클러뷰만 사용해서 아이템의 추가 및 삭제가 이루어지고 기타 기능도 복잡하지 않게 처리가능할거라 생각하고 있습니다.  일단 제 생각으로는요.
뭐 아이템의 추가 및 삭제가 비지니스 로직이면 로직일거같습니다.

그래서 말씀드렸다시피 C화면에서는 아직까지는 단순 입력화면이기는 합니다.
어디선가 데이터를 불러오는 일이없고 순수하게 데이터를 작성하는 페이지라서요.

선생님 두번째 답변을 읽어보니 그렇다면, 두가지 방법을 이렇게 이해했는데 맞을까요?

첫번째 방법,
B화면에서 입력한 데이터를 기존에 하던대로 B에서 저장하지 않고  A로 보내서 A에서 DB에서 저장.
B -> A 데이터 보냄 -> A에서 DB저장 형태

두번째 방법,
B에서 A로 데이터를 보내지않고 DB에 저장후 A로는 단순 화면만 전환하고 A에서는 DB에 저장된 데이터를 통해서 이를 바탕으로 데이터를 나열.
B에서 DB저장 -> A이동 -> DB바탕으로 데이터나열

이런 형태로 이해했는데 맞을까요? 맞다면 어찌됐든 결국 Repository가 필요는 한것같네요 결과론으로는..

---

네. 이해하신게 맞구요. B화면 같은 경우는 굳이 Repository가 필요없을 것 같아 보이네요. 네비게이션이든 로직이든 복잡하지 않는 게 좋으니까요.

---

아.. 오히려 Repository가 필요가 없군요? 그렇다면 데이터 추가와 같은 비지니스 로직은 그냥 ViewModel에서 구현을 해도 된다는 말씀이네요..

---

화면에서는 데이터를 입력받고 메모리에 보관하고 C에 넘겨주는 동작만 한다면요. 그리고 반복적으로 말씀드리지만, 님의 앱의 아키텍쳐는 님이 제일 잘 아는 사람이라, 최종결정은 복잡도, 테스트, 유지보수 등을 고려해셔 님이 결정하셔야 해요. 모든 아키텍쳐에서 장점과 단점, tr얻는 것과 잃는 것이 있습니다. 완벽한 방법은 없고 상황에 따라 결정되어야 합니다.

참고로 님과 같은 화면은 서로 연결된 하나의 유저 flow에 해당하기 때문에, 같은 scope을 가진 뷰모델을 공유하는게 자연스러워 보입니다. 물론, 현재 구조에서 가능하시다면 말이죠.
예를 들면, 비밀번호 변경과 같은 flow에서 현재 비빌번호 입력, 인증번호 발송, 인증번호 확인 등의 화면의 일련의 동작이기 때문에 화면이 다르더라고 데이터를 공유할 수도 있습니다.
뷰를 액티비티하나에 프레그먼트를 여러개 두어서 앞뒤의 네비게이션이 가능하도록 만드는 것이 좋겠지만, 액티비티만 사용하신다면, 별개의 뷰모델을 사용하시는게 쉬울 것 같네요.