-
728x90
Design Patterns
2022.03.06 - [ios/Etc] - GoF Design Pattern
MVC(Model - View - Controllers)
MVC (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴
간단한 쇼핑 리스트 앱이 있다고 해보자. 우리가 원하는 것은 이번 주에 사야할 각 항목의 이름, 개수, 가격의 목록이다. MVC 를 사용해 이 기능의 일부를 구현하는 방법을 아래에서 설명하겠다.
https://developer.mozilla.org/ko/docs/Glossary/MVC (view: controller = n:1 구조)
MVC 패턴의 구성 요소
- 모델(Model)
모델은 앱이 포함해야할 데이터가 무엇인지를 정의한다. 데이터의 상태가 변경되면 모델을 일반적으로 뷰에게 알리며(따라서 필요한대로 화면을 변경할 수 있다) 가끔 컨트롤러에게 알리기도 한다.(업데이트된 뷰를 제거하기 위해 다른 로직이 필요한 경우)
1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
2. 뷰나 컨트롤러에 대해서 몰라야 한다.
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
쇼핑 앱에서, 모델은 리스트 항목이 포함해야 하는 데이터(품목, 가격, 등)와 이미 존재하는 리스트 항목이 무엇인지를 지정한다.
- 뷰(View)
뷰는 UI와 관련된 것들이 포함된다. 사용자가 스크린을 통해서 보는 것들의 구조, 레이아웃, 형태 등을 정의하는 것이다.
1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
쇼핑 리스트 앱에서, 뷰는 항목이 사용자에게 보여지는 방식을 정의하며, 표시할 데이터를 모델로부터 받는다.
- 컨트롤러(Controller)
컨트롤러는 앱의 사용자로부터의 입력에 대한 응답으로 모델 및/또는 뷰를 업데이트하는 로직을 포함한다.
1. 모델이나 뷰에 대해서 알고 있어야 한다.
2. 모델이나 뷰의 변경을 모니터링 해야 한다.
예를 들어보면, 쇼핑 리스트는 항목을 추가하거나 제거할 수 있게 해주는 입력 폼과 버튼을 갖는다. 이러한 액션들은 모델이 업데이트되는 것이므로 입력이 컨트롤러에게 전송되고, 모델을 적당하게 처리한다음, 업데이트된 데이터를 뷰로 전송한다.
단순히 데이터를 다른 형태로 나타내기 위해 뷰를 업데이트하고 싶을 수도 있다(예를 들면, 항목을 알파벳순서로 정렬한다거나, 가격이 낮은 순서 또는 높은 순서로 정렬). 이런 경우에 컨트롤러는 모델을 업데이트할 필요 없이 바로 처리할 수 있다.
장점
- MVC 패턴의 장점은 널리 사용되고 있는 패턴이라 대중성이 좋다.
- 단순한 패턴
단점
- View와 Model 사이의 의존성이 높다.
- View와 Model의 높은 의존성은 어플리케이션이 커질수록 복잡하고 유지보수가 어려워진다.
MVVM(Model - ViewModel - View)
MVVM은 사용자 인터페이스(뷰)의 개발을 비즈니스 로직 또는 백-엔드 로직(모델)로부터 분리시켜서 뷰가 어느 특정한 모델 플랫폼에 종속되지 않도록 해주는 패턴. (이렇게 함으로써 테스트, 유지보수 측면이 용이해진다.)
MVVM View : ViewModel = n : 1 구조
MVVM 패턴의 구성 요소
- 모델(Model)
앱이 동작하는 앱 데이터를 조작하는 도메인 영역. 서비스의 데이터와 관련된 핵심 비즈니스 로직이 들어간다.
- 뷰(View)
뷰는 UI와 관련된 것들이 포함된다. 사용자가 스크린을 통해서 보는 것들의 구조, 레이아웃, 형태 등을 정의하는 것이다.
뷰는 UI로직 외에 비즈니스 로직을 포함해선 안된다. 모델을 보여서 표현하고 사용자와 뷰의 상호 작용(클릭, 키보드, 동작 등)을 수신하여, 이에 대한 처리를 뷰와 뷰 모델의 연결을 정의하고 있는 (속성, 이벤트 콜백 함수 등의) 데이터 바인딩(data binding, 데이터 연결)을 통하여 뷰 모델로 전달한다.
- 뷰 모델(View Model)
MVVM은 View로부터 input을 받아 모델을 업데이트하고 모델 output을 통해 뷰를 업데이트한다. 뷰가 사용할 메서드와 필드를 구현하고, 뷰에게 상태 변화를 알린다. 뷰 모델에서 제공하는 메서드와 필드가 UI에서 제공할 기능을 정의한다. 하지만, 뷰가 이 기능을 어떻게 보여줄 것인지를 결정한다.(View가 ViewModel 정보를 바인딩한다.)
바인딩은 주로 RxSwift나 Combine과 같은 FRP 라이브러리를 사용하고, KVO 패턴이나 Delegate 패턴, Property Observer 등을 사용할 수도 있다. 결과적으로 ViewModel은 데이터를 보내고 받는 역할만 가능하여 서로 간의 독립성이 완전히 확보됐다.
장점
- Viewdhk Model 사이의 의존성이 없다.
- Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성이 없다.
- 각각의 부분이 독립적이기 때문에 모듈화 하여 개발할 수 있다.
단점
- ViewModel의 설계가 어렵다.
MVVM의 장점
- Testable 하다.
- ViewModel을 재사용 단위로 설계할 수 있다.
- 구체적인 View를 알지 못하더라도 요구사항에 따라 ViewModel을 설계할 수 있다.
참고
https://m.blog.naver.com/jhc9639/220967034588
https://developer.mozilla.org/ko/docs/Glossary/MVC
https://www.raywenderlich.com/6733535-ios-mvvm-tutorial-refactoring-from-mvc
https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%8D%B8-%EB%B7%B0-%EB%B7%B0%EB%AA%A8%EB%8D%B8
728x90'ios > Etc' 카테고리의 다른 글
UITableView (0) 2022.06.03 Optional (0) 2022.05.27 AutoLayout (0) 2022.05.19 Stroyboard Components (0) 2022.05.19 Xcode 기능들과 AppProject 속성 (0) 2022.05.19