[team-11][Hong, Downey] 네트워크 통신 및 MVVM 구조를 통한 MainView 구성

[dahun-lee-daji]

작업 내용

1. Network + Combine을 사용하여 MVVM의 클린아키텍쳐를 지키도록 노력했습니다.
2. MVVM의 구조에서 Protocol을 사용하여 의존 관계를 끊으려고 하였습니다.
3. Mockoon을 이용하여 Network작동을 확인했습니다. ( MockAPI를 대체)
4. UICollectionViewDiffableDataSource를 사용하여 snapShot을 통한 view를 Reload하지 않도록 했습니다.

진행사항 체크리스트

• 상품 목록을 서버에서 가져오는 동안 Splash화면을 보여준다. -> 시간이 남는다면 구현 : 셀과 section을 만들 때 (datasource) 섹션과 상품 목록을 서버에 요청한다.
• 메인 화면은 NavigationView로, 3개의 section을 보여준다. (section의 표시 순서는 항상 동일하다)
• 섹션 헤더를 누르면 섹션의 상품 갯수를 보여준다. ( CocoaPods를 설치하여 toast형태로 적용한다.)
• 상품 이름, 상세 설명, 상품 가격은 DB에서 받은 그대로 표시한다. (상세 설명이 길 경우, linebreak를 Truncate Tail로 처리한다.)
• 뱃지 색상은 enum : String case에 따라 부여한다. Dictionary key:Value에 따라 부여한다.
• 전체 섹션 정보를 Client로 전달한다. iOS Client는 Network 준비를 마침.
• 전체 섹션 정보 형식을 작성한다.
• 네트워크 클래스를 작성한다.
• ~~ 테스트를 위한 Mock네트워크 클래스를 작성한다.~~ -> mockoon으로 테스트 진행.

학습 키워드

1. Network + Combine
2. MVVM
3. Clean Architecture
4. UICollectionViewDiffableDataSource
5. UICollectionView.CellRegistration

고민 & 질문 사항

1. 뷰모델은 뷰에 가까운 모델을 뷰모델이 가지고 있어야 한다고 알고 있습니다.
   
저희코드에서는 뷰모델에서 Dishes를 sink를 해서 바로 사용하고있는데., sink를 뷰모델에서 해야하는 걸까요?
   UseCase에서 sink를 해서 뷰모델로 넘겨주는게 맞는 걸까요?
2. UICollectionViewDiffableDataSource를 다른 클래스에서 생성하여 전달하고 있습니다. 이 클래스의 역할이 ViewController에 속하는 것이 맞을까요? 또, 이와 같이 구현하는 것이 옳을까요?
3. 많은 경우 DiffableDataSource를 <enum section, customDataClass>로 사용하고 있었습니다. 저는 section이 들어갈 자리에 이번 미션의 가장 큰 JsonData를 적용했는데, 이는 틀린 방법일까요?

[ChocOZerO]

고민 & 질문 사항

1. 뷰모델은 뷰에 가까운 모델을 뷰모델이 가지고 있어야 한다고 알고 있습니다.
   
 저희코드에서는 뷰모델에서 Dishes를 sink를 해서 바로 사용하고있는데., sink를 뷰모델에서 해야하는 걸까요?
   UseCase에서 sink를 해서 뷰모델로 넘겨주는게 맞는 걸까요?
2. UICollectionViewDiffableDataSource를 다른 클래스에서 생성하여 전달하고 있습니다. 이 클래스의 역할이 ViewController에 속하는 것이 맞을까요? 또, 이와 같이 구현하는 것이 옳을까요?
3. 많은 경우 DiffableDataSource를 <enum section, customDataClass>로 사용하고 있었습니다. 저는 section이 들어갈 자리에 이번 미션의 가장 큰 JsonData를 적용했는데, 이는 틀린 방법일까요?

1. 뷰모델을 뷰라고 생각하면 좀 더 이해가 쉬울 것 같습니다. 프로토콜 없이 그냥 뷰, 뷰모델이 있다면 뷰가 화면을 그리는데 필요한 정보들과 뷰의 interaction 정도가 뷰모델에서 관리되면 좋을 것 같습니다. 그리고 UseCase는 제가 어떤 아키텍쳐를 기준으로 대답을 드려야할지 명확하지 않네요. 원하시는 설계가 있다면 그 부분을 시각화해보시는걸 추천합니다.

2. 옳고 그런건 없고, 선택입니다. 복잡도를 줄이기 위해 CollectionView의 DataSource를 관리하는 객체를 만드는 선택을 하신거고, 나쁘지 않은 전략입니다. 덕분에 ViewController가 가벼워졌으니까요. 이 같은 선택은 화면이 복잡해질 수록 유리합니다.
   다만, Provider라는 이름에 맞지 않게 재사용성은 좀 떨어지는거 같아서 추상화, 일반화 과정을 거쳐 특화된 DataSource말고 여러 화면의 CollectionView에 맞출 수 있도록 설계되면 좀 더 좋을 것 같습니다. 이건 난이도가 좀 있어서 여유 있을때 도전해보시기를 추천드립니다.

3. Section을 enum을 사용하지 않고 커스터마이징하는건 상황에 따라 선택하실 수 있습니다. 다만 JsonData를 그대로 사용했다는 얘기는 API의 Response 모델을 그대로 사용했다는 얘기로 들리는데 맞는지 모르겠네요. 이 선택은 바람직하지 않습니다. 이유는 collection view라는 화면의 의존성이 API Response모델에 생기기 때문입니다. Response 모델이 변경되더라도 유연하게 대응할 수 있도록 독자적으로 모델을 만들어서 관리하시길 바랍니다.