디자인 아키텍처 3 - MVC

처음 개발을 시작할 때는 하나의 클래스 하나의 레이아웃 식으로 계획 없는 개발을 하였다. 규모가 작은 앱인 경우에는 문제가 없겠지만 규모가 크거나 복잡한 로직의 앱은 문제가 된다. 가령 예를 들어 개발하다 보면 많은 요구사항과 복잡한 기획이 요구가 될 것인데 디자인 패턴 없이 개발을 진행했다면 변경이 될 때마다 화면을 구성하는 코드와 비즈니스 로직이 들어간 코드 각각 모두 동시에 매번 수정해야 하는 번거로움이 생긴다. 다시 말해서 서로 간의 의존성이 강해질 수 록 유지보수는 힘들어진다.

위와 같은 문제점을 해결하기 위해 나온 방법 중 하나가 MVC이다. MVC는 Model, View, Controller의 약자이다. MVC 구조에서는 유저의 입력이 Controller에서 발생한다. 이에 따라 Controller이 Model과 View에 알려주는 형식이다.

Model

• 데이터를 가지고 있으며 해당 데이터의 읽기/쓰기가 가능함
• View와 Controller에 의존하지 않아 재사용이 가능함

View

• 유저에게 보일 화면을 표현
• 유저들에게 모델의 정보를 보여줌

Controller

• 유저로부터의 액션을 받고 이를 Model에 의해 View를 정의함
• Model에 명령을 보냄으로써 모델의 정보, 데이터를 변경함

안드로이드 MVC

MVP 구조

1. Activity에서 이벤트 발생
2. Model로부터 데이터 업데이트 여부 체크
3. Model로부터 받은 데이터를 통해 View 갱신 여부 판단
4. View에서 UI 갱신

MVC는 안드로이드 말고도 개발에서 사용하는 패턴으로 안드로이드에서 사용하는 MVC 같은 경우에는 Model과 Controller가 합쳐진 구조이다. Model과 Controller의 역할을 하는 곳이 Activity와 Fragment이다. 따라서 하나의 클래스에 MVC 구조 설계가 가능하다. 기본적인 flow는 사용자가 발생시킨 Event에 따라서 Controller가 발생한 이벤트를 Model에 전달하고 데이터에 변화가 있으면 View에 표시하는 것이다.

View와 Controller 예시

class MvcActivity : AppCompatActivity() {
    
    private lateinit var button: Button
    
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_mvc) //UI를 생성 -> View
        button = findViewById(R.id.mvc_button)
        button.setOnClickListener{
          //버튼 클릭 시의 리스너 -> Controller  
        }
    }
}

위의 코드와 같이 하나의 클래스 안에 View와 Controller가 존재한다.

Model 예시

data class Member(
    val id: Long,
    val name: String,
    val age: Int
)

데이터를 가지고 있는 클래스

MVC의 장점

• Activity 또는 Fragment에 모든 것을 설계함으로써 개발기간 감소
• Model의 비종속성으로 인한 재활용 가능
• 코드를 쉽게 파악 가능
• 구현이 쉬움

MVC의 단점

• 유지보수가 어려움
• 하나의 클래스에 모든 코드가 있으므로 코드 양의 증가
• View와 Model의 결합도 상승
• Controller가 안드로이드 Api 종속
• 유닛 테스트 어려움