PageViewController의 과도한 분리에 대한 토론

[youz2me]

현재 위 화면은 PageViewController를 이용해 구현된 상태입니다. PageViewController가 약속 상세 VC, 준비 현황 VC, 지각 꾸물이 VC를 컨테이너처럼 담고 있는 구조인데요. VC마다 서버와 통신해야 할 부분이 있고 데이터 바인딩이 필요해 VM과 Service를 구현하는게 맞다고 생각했습니다.
VC는 4개인데 VM과 Service는 1개면 총 통신해야 할 API가 위 화면에서 8개나 되는 상황에서 혼란도 커질 것 같았고 각 화면이 전환될 때마다 통신과 바인딩이 이루어지기 때문에 VM과 Service를 분리하는 게 참조 측면이나 컨벤션적으로도 더 맞을 것 같다고 생각했기 때문입니다!

그래서 그에 맞춰 구현된 구조는 다음과 같습니다.

그런데 위와 같이 구현했을 때 생기는 문제점이 있습니다.
해당 화면으로 넘어올 때 promiseID를 생성자로 주입받습니다. 이 promiseID가 이 화면에서 통신해야 하는 모든 API의 request 값으로 들어가는데요. 이 경우 promiseID를 세 VC의 생성자로 다시 주입해주어야 합니다. 저는 이 부분이 가장 불필요한 부분이라고 생각해서 세 VC 자체를 없애고 싶었어요. 그래서 PageViewController를 PromiseViewController로 리팩토링한 후 모든 VC의 내용을 PromiseViewController로 합치려고 했습니다.

그래서 이 부분이 #269 에서 진행한 부분입니다.
근데 합쳐놓고 보니 생각보다 리팩토링 코스트가 너무 크고 PromiseViewController, ViewModel, Service의 크기가 엄청 커져서 이 부분에 대한 조언을 얻고자 합니다.

지금 상황에서 선택할 수 있는 선택지는 다음과 같습니다.

1. VC, ViewModel, Service가 모두 분리되어 있는 현재의 상태 유지
2. VC를 분리하고 ViewModel과 Service만 합치는 방향으로 재리팩토링

아마 위처럼 될 것 같습니다.
3. 원래 하려고 했던 것처럼 VC, ViewModel, Service 모두 병합

보시고 의견 주세요! 부족한 부분 있으면 물어봐주셔도 괜찮습니다.
감사합니다.

[JinUng41]

제가 직접적으로 의견을 주었던 부분인지라 글을 봐도 이해하기에 편했네요.
다이어그램까지 그려주시니 더욱 이해하기가 편했습니다.

다만 현재의 상태에서는 코드적으로 명확한 단점이 존재합니다. 물론 제가 못 받아 들이는 걸수도 있지만요.
화면의 가지 수를 3가지로 나누되, 그것을 보여주는 화면을 하나로 묶는다고 본다면 ViewModel이 하나만 존재하는 것이 보다 구현하기에 편할 것이라고 생각했어요.
물론 그만큼 하나의 ViewModel이 비대해 질 수 있지만요. 아무래도 갈라지는 내부의 화면에서 공유해야 할 데이터가 존재하다 보니 이렇게 구조가 만들어 진것이라고 생각합니다.
저도 정답은 모르겠습니다만, 저로썬 공유해야 할 상태가 많은 현재의 상태에서는 하나의 ViewModel로 공유하되, ViewModel 자체가 비대해 질 수 있겠지만, 많은 노력을 기울이고 리팩토링을 진행한다면 깔끔한 코드를 구현할 수 있을 것 같습니다.

위와 관련된 내용은 저도 추가적으로 고민해보고 공부해보겠습니다.

[youz2me]

좋은 의견 감사합니다 !! 코드적으로 명확한 단점이라고 한다면 아무래도 쓸데없는 데이터 전달이 많아서 생기는 문제점들이겠죠...? 양이 많아진다거나 코드가 복잡해지는 등 ... 제가 이해한게 맞는지 모르겠네요 ㅠㅠ

저도 진웅님 의견에 동의합니다! ViewModel을 합치는 쪽으로 고민해볼게요 ㅎㅎ 감사합니다