오늘은 멘토님께서 저에게 일요일에 SLACK 으로 메세지를 보내셨습니다.

멘토님 : Assist 님 저번 멘토시간에 말했던 Model 관련해서 좋은 영상이 있어서
한번 가져왔습니다. 한번 보세요 

저(Assist) : 오! 감사합니다

링크 : https://tv.naver.com/v/9329728

안드로이드에는 여러 디자인 패턴이 있다

학생때부터 지겹게 들은 이야기가 있습니다. 바로 디자인패턴
예를들어 MVC , MVVM , MVP etc... 등 여려 디자인 패턴을 이야기 한적이 있습니다.

근데 여기서 자세히 보면 공통적으로 들어가는 단어들이 있습니다.

MVC , MVP , MVVM -> "M"

그럼 여기서 M 은 무엇을 뜻할까요?
바로 모델(Model) 입니다. 그럼 모델의 역활은 뭘까요?

Model 의 역활

여러 정리 글이 있겠지만 모델의 역활은 이렇게 생각합니다

DB , API 호출 ,비즈니스 로직 담당

영상에서는 모델을 Domain data Source 로 나눴습니다.

API 호출에는 Repository Pattern 을 사용했더군요

그럼 한번 가봅시다

Repository Pattern

Repository 패턴은 구글에서 권장하는 패턴입니다.

역활은 데이터 불러오는 로직을 분리시켜서 관리하는것 입니다.

class RepositoryImpl(private val api : ApiService) : Repository {
	override fun getApi(userName : String) : Repo = api.getApi(userName)
    }
 
 interface Repository{
 	fun getApi(UserName : String) : Repo
 }   

그래서 이 Repository Pattern 의 장점은 뭐야 ?

• 추상화를 통하여 테스트가 용이해진다
• 데이터를 불러오고 처리하는 역활을 분리

입니다.

Business Logic 은 무엇인가

뭐 예를들어 Repository 에서 데이터를 불러오고 하는 역활이 끝나면

• 데이터를 가공하는 로직 입니다

좀 더 쉽게 생각한다면
repository 에서 데이터를 가져옴 -> 그것을 가공해서 View로 넘거줌 -> View Show

이런것입니다.

그럼 Repository에서 하면 되잖아

뭐 그것도 방법이긴 합니다만.....

• 복잡한 화면일수록 Repository에 복잡성이 높아진다
• 그로인한 유지보수 , 기능추가가 어렵다

입니다.

제 이전 포스트 Naver 검색 API 에서는 ViewModel에서 view을 위한 데이터 가공을 했는데 여기서는 Usecase 라는것을 사용했네요

개인적인 생각으로는

@HiltViewModel
class SearchViewModel @Inject constructor( private val repository : RepositoryImpl) : ViewModel() {

    private var _bookSearchLiveData = repository.getBookLiveData()
    val bookSearchLiveData get() = _bookSearchLiveData

    private var TAG = "SearchViewModel"
//    private val test = LiveData<>()

    /**
     * 책 검색 api
     */
    fun requestBookApi(id: String, pw: String, query: String) =viewModelScope.launch(Dispatchers.IO) {
        _bookSearchLiveData.postValue(Resource.loading())

        repository.requestBookApi(id, pw, query)
//        _bookSearchLiveData.postValue(repository.getBookLiveData().value)
//        _bookSearchLiveData.value = repository.getBookLiveData().value
    }

    fun requestSaveSearchList(query :String) = viewModelScope.launch(Dispatchers.IO) {
        val time = CompanionFunction.getCurrentDateTime()
        val data = SearchList(time , query)
        repository.requestSaveSearchList(data)
    }

    override fun onCleared() {
        super.onCleared()
        Log.d(TAG , "The SearchViewModel is Clear")
    }
}

해당 코드는 제 ViewModel 입니다.
이처럼 작은 기능에서는 굳이 Usecase을 필요는 안할거 같지만
저희는 작은 프로젝트만 하기위해 개발자를 하는것이 아니기 때문에 한번 Usecase라는것을 공부를 해봐야 겠네요.

그럼 다음시간에는 Usecase을 한번 제 Naver 검색 api에 적용해보는 시간을 가져 보겠습니다

-읽어주셔서 감사합니다-
-피드백와 비판은 언제나 환영입니다-