MVC 디자인 패턴
- 애플리케이션 구조를 Model, View, Controller 세 가지 주요 측면으로 관심사를 분리한다.
Model의 역할
- 애플리케이션의 비즈니스 로직과 사용되는 데이터를 다루는 영역이다.
표현되는 형식에 의존적이지 않고, 사용자에게 보이지 않아 어떻게 보일지를 신경쓰지 않아도 된다.
일반적으로 비즈니스 데이터는 DBMS에 의해 관리되고 몇몇 함수를 통해 데이터를 제공하거나 입력, 수정 등을 하는 역할을 한다. 안드로이드에서는 데이터베이스의 Entity를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm 등이 될 수 있다.
View의 역할
- 사용자에게 표현되는 영역이다. Model로부터 얻은 데이터를 View에서 표현하며, 안드로이드에서는 Activity, Fragment가 View의 역할을 한다.
Controller의 역할
-
Model과 View에 의존한다. View로부터 입력을 받거나 특정 이벤트가 발생할 때 Model 또는 View를 변경할 수 있다.
-
ex) 전화번호부 애플리케이션에서 전화번호를 등록한다고 할 때 사용자가 입력한 전화번호 및 기타 정보를 View로부터 입력받으면 Controller는 해당 데이터를 Model로 전달하여 데이터베이스에 입력한다. 이 때 Model의 상태가 바뀌면 Model은 등록된 View에 자신의 상태가 바뀌었다는 것을 알리고 View는 거기에 맞게 사용자에게 Model의 상태를 보여준다.
-
MVC 디자인 패턴에서 Activity와 Fragment는 View의 역할을 하지만 Controller의 역할을 하기도 한다.
-
Controller는 View와 Model에 의존하며, View는 Model의 상태 변화에 따라 능동적으로 대응할 수 있다.
MVC 장단점
장점
- 직관적이다.
-> Model에서 데이터를 얻어서 View에 표현하고 이 모든것을 Controller가 중개한다. 구조가 단순하고 직관적이다. - 규모가 작은 애플리케이션에 MVC 디자인 패턴 적용 시 개발 기간이 짧아지고, 거의 모든 코드가 Activity나 Fragment 같은 Controller에 작성되는 경향이 있어 코드를 파악하기 쉽다.
단점
- 액티비티 또는 프래그먼트가 View와 Controller의 역할을 겸하는 구조라 코드량이 점진적으로 증가할 수밖에 없고, 그로 인해 하나의 Activity 또는 Fragment 클래스에서 코드가 길어진다
-> 스파게티 코드가 되기 쉬워, 시간이 지남에 따라 유지보수비가 증가한다. - Controller는 View와 Model에 의존적이고, 뷰는 Model에 의존적이라 결합도가 높아 유닛 테스트가 거의 불가능하다.
반가워요!