앱의 아키텍처에서 UI 레이어와 데이터 레이어의 로직을 분리하여 사용하라는 말을 들었을 것이다. 또한 데이터 레이어는 뷰모델에 제공할 여러 개의 데이터 소스를 포함해야 하며, 다양한 유형의 데이터마다 저장소각각의 (repository) 클래스를 만들어 사용한다고 한다.
Problem
그럼 각각의 관심사가 나뉜 Fragment A, B에서 겹치는 관심사가 생겼을때 어떻게 해야할까?
A Framgent에서 변경한 상태에 대해 B Fragment에서 변화가 필요하다.
-
A, B 프래그먼트 모두 각 뷰모델을 설정한다.
-
하나의 뷰모델로 SharedViewmodel형태로 선언하여 사용하는 것이 좋을까?
각각의 뷰모델을 생성한다면 뷰모델의 코드를 줄일 수 있지만, 한 프래그먼트가 2개의 뷰모델을 사용하게 되고, 이것이 비효율적일 수도 있다고 생각하였다. 그렇다고 하나의 뷰모델을 사용하자니 뷰모델의 크기가 방대해진다.
어떻게 하면 좋을까??
Solution
관심사분리는 절대로 나쁜일이 아니다. 각각의 파일, 클래스가 하나의 일에대해 책임을 가지는것은 이상적이다.
앱을 작성하며 코드가 불어날 때, 분리되지 않은 코드는 훨씬 더 복잡해진다. 그럼으로 당장 여러개의 뷰모델을 가지는 것은 과도한 것 같지만, 이는 후에 갔을 때 후회하지 않을 일이다.
여러개의 프래그먼트에서 SharedViewmodel을 사용하여 각 프래그먼트와 소통하는 것은 이상적이다. (ActivityScope에서의 뷰모델을 사용해야 하겠지만)
지금 당장 두 가지 접근 방식을 모두 사용할 수 있지만, 어떤 것이 확실한지는 장담할 수 없다.
// 원문
Separation of concerns is almost never a bad thing.
Ideally, each file/class should be responsible for one thing.
Additionally, you never know how the code will grow.
Things tend to only get more complex over time, not usually simpler.
So, while having multiple viewModels right now may feel like overkill, it will likely pay off later.
One case where a shared viewmodel between several fragments is ideal is
when the fragments need to communicate with each other - they all would then use the activity viewmodel.
I would assume in this case you can use both approaches,
though I have never done it, so I can't say for certain.하나의 큰 뷰모델 또는 작은 여러개의 뷰모델을 사용하는 것을 방지하여 Bundle 및 args를 사용하여 프래그먼트를 만들 때 정보를 보내는 방법을 사용하기도 한다.
