[아키텍처패턴] 1탄 : Model 분리하기

모든 코드를 뷰에 다 때려 박던 김 모 씨는 코드 관리의

필요성을 느끼고 아키텍처 패턴을 공부하기 시작하는데

 

 

---

아키텍처 패턴을 사용하는 이유

1. 코드 각각의 역할을 나눠 코드관리를 직관적으로 하는 게 유지보수와 협업에 좋다.

2. 모듈은 한 가지 기능만 하도록 세분화 되어야 한다.

3. 리소스의 낭비가 없어야한다.

 

Model이란 무엇인가

어떠한 동작을 수행해주는 코드입니다. 사용자에게 어떻게 보일지 신경을 쓰지 않아도 됩니다. (이러한 부분은 View 부분에서 할 일입니다.) 예를 들어 데이터, DB, 알고리즘 등이 Model에 속합니다.

 

Model을 분리하는 이유

Model과 View 간의 결합도를 낮추면, 새로운 기능을 추가하거나 수정할 때 관련된 부분만 변경하면 되기 때문에 코드 유지보수에 유리합니다. 그리고 테스트 코드를 작성하기 편리해져서 더 안전한 코드 작업이 가능합니다.

 

 

 

---

Repository pattern을 적용해보자

 

필요성 

데이터 저장소(remote 혹은 local)에 접근할 때 직접 접근을 하게 되면, 부작용을 초래할 수 있습니다.

 

(부작용)

- 중복된 코드 사용

- 프로그래밍 에러 발생 확률 상승

- 캐싱과 같은 데이터-관계 정책 중심화 어려움

 

-> 모델과 프레젠터 사이의 일종의 중간 다리 역할을 해서 둘 사이의 의존성을 줄입니다.

 

 

사용

1. 리모트 데이터를 받는 인터페이스 작성

interface NaverRemoteDataSource {
    fun getMovieData(title: String, onResponse: (NaverApi) -> Unit, onFailure: (Throwable) -> Unit)
}

 

2. 인터페이스를 상속해 실제 구현하는 코드 작성

class NaverRemoteDataSourceImpl : NaverRemoteDataSource {
    override fun getMovieData(
        title: String,
        success: (NaverApi) -> Unit,
        fail: (Throwable) -> Unit
    ) {
        NaverSevicelmpl.service.getMovie(title).enqueue(
            object : retrofit2.Callback<NaverApi> {
                override fun onFailure(call: Call<NaverApi>, t: Throwable) {
                    fail(t)
                }

                override fun onResponse(call: Call<NaverApi>, response: Response<NaverApi>) {
                    success(response.body()!!)
                }

            }
        )
    }
}

 

3. 레포지토리 클래스에서 함수 호출(remote와 local 구분)

  - local 부분은 구현 안함.

class NaverRepository {
    var NaverRemoteDataSourece: NaverRemoteDataSource = NaverRemoteDataSourceImpl()

    fun getMovieData(title: String, success: (NaverApi) -> Unit, fail: (Throwable) -> Unit) {
        NaverRemoteDataSourece.getMovieData(title, success, fail)
    }
}

 

---

결론

 

 View는 보여주고 입력받는 역할인데, 제가 이전까지 구현하던 방법에서는 데이터를 가져오는 역할까지 하고 있어서 덩치가 컸습니다.

그래서 이런 식으로 retrofit2 라이브러리를 통해 불러오는 로직을 뷰에서 분리시킬 수 있습니다. 뷰의 역할이 한층 줄어든 것입니다.

 

이상적인 MVP 모델의 구현 방향

 

 

다음은 MVP 패턴을 적용해보는 과정을 포스팅하겠습니다.

 

---

참고 자료

https://imcreator.tistory.com/105

[Repository Pattern] Android MVP에서 사용되는 데이터 분리 패턴

https://vandbt.tistory.com/27

Repository Pattern - in MSDN