MVC to MVP Migration

💡 우아한테크코스 과정을 진행하면서 MVC 디자인패턴을 MVP로 마이그레이션을 진행한 이유와 과정에 대하여 기록하였습니다!

 

개요

• 이전에 MVC 패턴에 대하여 학습하였습니다.

[디자인패턴] MVC

[디자인패턴] MVC

• 하지만 MVC 패턴으로 구현 후 테스트와 의존성 관련해서 문제점이 있다는 것을 알게 되었고, 이를 보완한 MVP 패턴에 대해서 학습하였습니다.

[디자인패턴] MVP

[디자인패턴] MVP

• MVC패턴을 MVP 패턴으로 마이그레이션 했을 때 얻는 이점과 과정을 정리해보려 합니다.

MVC

• 우아한테크코스 과정 초기에 MVC 패턴을 주로 활용하였습니다.
• MVC 패턴에서 컨트롤러는 뷰로부터 유저의 이벤트로 모델을 변경하여 다시 컨트롤러에 전달해 뷰를 업데이트 합니다.
• 이러한 과정에서 모델과 뷰를 분리하긴 하였지만, 컨트롤러가 지나치게 비대해지는 과정이 발생하였습니다.
• 또한 초기에는 주로 콘솔을 활용한 I/O 프로그램을 구현하였지만, Activity를 활용하는 안드로이드 프레임워크로 넘어가면서 문제가 생기게 되었습니다.

MVC with Android

View와 Controller의 강한 결합

• 안드로이드에서는 xml 파일을 통해서 View를 보여주고, 해당 View의 이벤트나 변화를 받아 동작을 수행하는 액티비티가 존재합니다.
• 일반적으로 xml과 activity는 1:1 관계로 구성되는데, 이로인해 Controller가 activity의 로직과 동일해지고 Activity에서는 뷰 로직과 Controller의 역할을 동시에 담당하게 됩니다.

Activity or Fragment의 과도한 책임

• God Object 문제 발생
  • Activity, Fragment가 View와 Controller의 역할을 동시에 수행하면서 코드의 양이 급격하게 증가하고 복잡해집니다.
  • 이를 Got Object 문제라고 하며, 한 클래스에 너무 많은 책임이 집중되는 현상을 의미합니다.
• 이로 인해 작은 변경에도 큰 영향을 미칠 수 있으며, 버그 발생 가능성과 코드 가독성이 저하됩니다.

어려운 테스트

• Controller와 View의 강한 결합으로 비즈니스 로직을 독립적으로 테스트하기 어렵습니다.
• Activity나 Fragment는 Android 프레임워크에 강하게 의존하므로, 단위 테스트를 위해서 복잡한 Mocking이 필요합니다.
• 테스트 코드가 복잡해지고, 테스트 커버리지가 낮아지는 단점이 있습니다.
• [테스트 커버리지] : 시스템 소프트웨어에서 테스트가 얼마나 충분한가를 나타내는 지표로, 수행한 테스트가 대상을 어마나 커버했는지 나타냅니다.

비즈니스 로직과 UI 로직의 혼합

• MVC 패턴에서 로직이 복잡해질 경우 비즈니스 로직과 UI 로직이 혼합되는 경우가 많습니다.
• 이로 인해 코드의 모듈화가 떨어지고, 코드 변경으로 인한 버그 발생 가능성이 높아집니다.

MVP로 마이그레이션하는 이유

테스트 가능성 향상

• MVC에서는 Controller가 View에 강하게 결합되어 있어 테스트가 어렵지만, MVP는 Presenter가 인터페이스를 통해 View와 상호작용하기 때문에 단위 테스트가 용이합니다.

유연성 증가

• View Presenter의 명확한 분리로 인해 UI 변경 시 Presenter를 수정할 필요가 없으므로 더 유연한 구조를 제공합니다.

코드 유지보수성과 재사용성

• 각 컴포넌트의 역할이 더 명확하게 분리되어 있어 유지보수와 확장이 용이합니다.
• Presenter가 로직을 담당하므로, 다른 View에서도 동일한 Presenter를 사용할 수 있어 코드 재사용성을 높일 수 있습니다.

마이그레이션 진행하기

• 실제로는 Contract Interface를 활용하여 View 인터페이스와 Presenter 인터페이스를 한 곳에서 관리하였지만 마이그레이션 하는 과정을 위해서 분리하였습니다.

View Interface 생성

• MVC 구조의 View에서 인터페이스를 추출하였습니다.

interface MainView {
    fun showLoading()
    fun hideLoading()
    fun showData(data: List<String>)
    fun showError(error: String)
}

Presenter 클래스 생성

• MVC의 Controller 역할을 했던 로직을 Presenter로 이동하였습니다.
• Presenter는 View 인터페이스를 의존성으로 가지며, View와 Model 간의 상호작용을 처리합니다.

class MainPresenter(private val view: MainView, private val model: DataModel) {

    fun loadData() {
        view.showLoading()
        val data = model.fetchData()
        if (data.isNotEmpty()) {
            view.showData(data)
        } else {
            view.showError("No data found")
        }
        view.hideLoading()
    }
}

기존의 View 클래스에서 Presenter 사용

• 기존의 Activity나 Fragment를 Presenter와 상호작용하도록 변경합니다.
• View 인터페이스를 구현하여, MainView의 함수들을 오버라이딩 하였습니다.

class MainActivity : AppCompatActivity(), MainView {

    private lateinit var presenter: MainPresenter

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // Model 초기화
        val model = DataModel()

        // Presenter 초기화
        presenter = MainPresenter(this, model)

        // 데이터 로드
        presenter.loadData()
    }

    override fun showLoading() {
        // 로딩 표시
    }

    override fun hideLoading() {
        // 로딩 숨김
    }

    override fun showData(data: List<String>) {
        // 데이터를 UI에 표시
    }

    override fun showError(error: String) {
        // 에러 메시지 표시
    }
}

테스트 코드 작성

• MVP 패턴이 테스트 작성에 용이한지 확인하기 위해서 테스트 코드를 작성해보았습니다.
• Mocking 라이브러리(Mockito)를 활용하여 View를 모의 객체로 만들고, Presenter의 동작을 검증하였습니다.

class MainPresenterTest {

    private val mockView = mock(MainView::class.java)
    private val mockModel = mock(DataModel::class.java)
    private lateinit var presenter: MainPresenter

    @Before
    fun setup() {
        presenter = MainPresenter(mockView, mockModel)
    }

    @Test
    fun testLoadData() {
        val dummyData = listOf("Data1", "Data2")
        `when`(mockModel.fetchData()).thenReturn(dummyData)

        presenter.loadData()
        
        // verify를 통해서 동작 확인
        verify(mockView).showLoading()
        verify(mockView).showData(dummyData)
        verify(mockView).hideLoading()
    }
}

결론

• MVC 패턴은 MVP 패턴으로 마이그레이션 하였습니다.
• 이로 인해서 아래와 같은 이점을 얻을 수 있었습니다.

유연성 증가

• MVP로 마이그레이션함으로써 View와 Presenter의 분리가 명확해졌습니다.
• 이로 인해 유지보수와 코드 관리가 쉬워졌습니다.

테스트 가능성

• 기존에 Controller를 테스트하기 어려웠지만, Presenter로 전환하여 View와의 의존성을 감소시켰습니다.
• 이로 인해서 UI 로직을 Presenter에서 독립적으로 테스트할 수 있어서 단위 테스트 작성이 용이해졌습니다.

개발 생산성

• Presenter와 View가 독립적이기 때문에 UI 변경 시 비즈니스 로직의 변경이 필요 없어 개발 속도가 빨라집니다.