iOS 앱 개발을 하다보면 여러가지 디자인 패턴을 마주하게 된다.
특히 자주 사용되는 디자인 패턴으로는 UIKit의 MVC, Swift UI의 MVVM이 있다.
MVC
Model, View, Controller
세 가지 계층(Model,View, Controller)으로 각 코드의 책임과 역할을 나눕니다.
Model
데이터와 관련된 내용을 담고 있을 뿐만 아니라 데이터를 관리하는 로직도 포함하고 있습니다.
네트워크를 통해 받아온 DTO 구조체와 네트워크에 접근하는 로직, 파일로 따로 저장해야하는 Persistance한 데이터를 로드, 필요한 구조체를 만드는 경우 해당 내용들은 모두 Model에 포함됩니다.
UI와 직접적으로 연결되지 않으며, MVC 패턴을 제대로 활용하기 위해서는 Model은 받아온 데이터를 그에 맞춰 저장할 형태를 만드는 것이 중요하지 UI에서 어떻게 보일지는 신경쓰지 않는 것이 좋습니다.
Model에 들어가는 코드
1. 데이터로 사용하는 구조체: ex) struct Person {let name, birthDate}
2. 네트워크 로직: 네트워크 요청을 하고, 그 결과를 받아오는 기본적인 기능을 담은 네트워크 로직
3. Persistance 로직: 메모리에 저장되는 데이터를 로드 및 세이브하는 로직
4. 데이터 파싱 로직: 네트워크나 내부 파일에서 받아오는 데이터(Json 등)가 왔을 때 이를 파싱하는 로직
5. Manager 객체(shared 객체): 구조체를 만들어두고 필요한 경우에는 어디서든 접근해 사용할 수 있도록 따로 Manager를 만드는 경우
6. Util, Extension, Constant: 앱으로 따지면 우리가 정의하는 Color나, String의 추가적인 기능, 혹은 특정 사이즈에 대한 정보를 util, extension, constant로 많이 만들게 되는데, 이런 경우에도 사용함
view
View는 흔히 말하는 UI
유저들에게 데이터를 보여주고, 어떻게 보여줄지 화면을 구성하는 코드들이 포함되어있습니다.
또한 View 계층은 직접 유저와 상호작용을 하며, 상호작용을 Controller 계층으로 전달하는 역할을 합니다.
재사용성
화면에 들어가는 여러 요소들을 어떻게 잘 나누어서 앱 전반에서 재활용할 수 있도록 할지가 중요합니다.
예를 들면, 앱 전반에서 일관적으로 사용되는 디자인의 버튼이 있다고 가정했을 때, 필요할 때마다 해당 디자인을 다시 코드로 작성하는 것이 아니라, 재사용할 수 있도록 MyButton 이런 덩어리를 따로 만들어서 관리하면 보다 코드가 깔끔해집니다.
View에 주로 들어가는 코드
- 주로 UIView를 상속해 만들어진 subclass
- Core Animation
- Core Graphics
Controller
앱의 핵심 로직을 담고 있는 계층
Controller는 View, Model에 연결되어 그 중간의 역할을 하고 있으며, MVVM 패턴에서 ViewModel이 하고 있는 역할과 비슷하다고 볼 수 있습니다.
View에서 보여주기 위한 데이터를 이 Controller가 보내주면서 View를 refresh하고, 그 데이터를 Model으로부터 가져오는 기능을 합니다.
View로부터 유저와의 상호작용에 대한 정보를 받고, 그 정보를 바탕으로 해당된 로직을 실행하고 Model의 정보를 업데이트하는 기능도 포함됩니다.
Controller는 해당 View마다 하나씩 붙어서 그 View에 맞는 로직을 포함하고 있기 때문에, 재사용성은 View보다 떨어지며, 재사용성이 적다보니 코드가 길어지는 경우가 많습니다.
Controller, UIKit UIViewController?
컨트롤러는 Model과 View에 모두 연결되어 있어 그 역할에 따라 또 두 가지로 나눌 수 있습니다.
-
Model Controller
Controller가 Model을 가지고 있습니다.
이 Model Controller는 Model의 데이터를 관리하고, View에 데이터를 전달하는 역할을 하게됩니다. -
View Controller
Controller가 View를 가지고 있습니다.
View를 관리하고 유저와의 상호작용도 관리하며, Model의 데이터를 업데이트하는 역할을 하게 됩니다.
MVVM
Model, View, ViewModel
MVVM은 그래픽 사용자 인터페이스(뷰)의 개발을 비즈니스 로직 또는 백-엔드 로직(모델)로부터 분리시켜서 뷰가 어느 특정한 모델 플랫폼에 종속되지 않도록 해주는 패턴
Model
-
데이터, 네트워크 로직, 비즈니스 로직등을 담으며 데이터를 캡슐화하는 역할을 맡고 있습니다.
-
View, ViewModel에 대한 신경은 쓰지 않고, 데이터를 어떻게 가지고 있을지만 걱정하며, 데이터가 어떻게 보여질 것인지에 대해서는 고려하지 않습니다.
즉, MVC의 Model과 크게 다르지 않습니다.
View
-
사용자가 화면에서 보는 것들에 대한 구조, 배치, 그리고 외관에 해당하는 내용을 다룹니다.
-
Model을 직접 알고 있어서는 안됩니다.
위의 두가지는 MVC에서의 View 역할과 비슷합니다.
-
View는 ViewModel로부터 데이터를 가져와서 표현합니다.
-
사용자와 View의 상호 작용을 수신하고 이에 대한 처리를 ViewModel에 부탁하게 됩니다.
데이터를 보여주고, 사용자와의 상호작용 처리를 다른 객체에게 넘긴다는 점에서 이 부분도 MVC의 View와 비슷해보이나, MVC, MVP와는 다르게 MVVM의 View는 보이는 부분에 대한 설정을 스스로 직접 하게 됩니다.
ViewModel
-
View로부터 전달받는 요청을 처리할 로직을 담고 있으며 Model에 변화가 생기면 View에 notification을 보냅니다.
-
ViewModel은 View와 Model 사이의 중개자 역할을 하며 Presentation Logic을 처리하는 역할을 합니다.
중간다리 역할을 한다는 점에서 MVC 패턴의 Controller와 유사하다고 볼 수 있습니다.
MVC vs MVVM
-
MVC : 기본적으로 View와 Model은 다른 구성요소들을 알지 못하며, Controller는 View와 Model을 모두 알고있는 형태로 구현되어야 했습니다.
MVVM : View는 ViewModel을 알고 있으며, 소유합니다.
ViewModel은 Model만을 알고 있도록 구현되며, Model은 다른 구성요소들을 알지 못하도록 만들어져야 합니다. -
MVC: View가 데이터를 보여주는 방식은 크게 두 가지로 나뉘었습니다.
Model에 View를 Observer로 등록하여 데이터를 설정하는 방식 (Model이 View를 알고 있는 형태)
ViewController가 Model의 변경을 알아차리고 직접 View에 데이터를 설정해주는 방식(apple's MVC)
MVVM: View는 ViewModel과의 데이터 바인딩을 통해 스스로 데이터를 보여줍니다.(데이터를 View에 보이게 하기 위한 설정 책임을 View 스스로가 가짐) -
MVC(iOS): 사용자 상호작용에 대해 View가 Controller에게 처리를 부탁하는 것은 Delegate Pattern, Target-Action등을 사용했습니다.
MVVM: View가 ViewModel을 알고 있으므로 필요할 때 ViewModel의 메서드를 호출하는 방식으로 구현이 가능합니다.
