MVC의 탄생 Smalltalk MVC
MVC의 탄생은 1970년대 GUI Applicataion에 적합한 구조를 설계 구조를 고민하다 나오게 된 구조로 알려져있다.
Form 과 Widget
- 폼은 iOS의 ViewController와 유사한 레이아웃이며, UI 전체의 이벤트 핸들링을 담당한다.
- 위젯은 버튼, 테이블뷰와 같은 UI 컴포넌트와 유사하다.
이 당시 개발방법은 각각의 UI 컴포넌트안에 모든 코드를 작성하는 것이다.
- 위젯을 폼에 배치하는 입장에서 보면 위젯안에 어떤 코드들이 있는지 신경쓰지 않고 배치할 수 있었기 때문에 좋은 분리라고 여김
Trygve Reenskaug
- 코드가 위젯의 프레젠테이이션과 얽혀있기 때문에 좋은 분리가 아니라고 주장
- 에디터 : 프레젠테이션을 담당하는 계층
▸ 에디터는 다시 입력과 출력을 담당하는 부분으로 분리
- 컨트롤러 : 입력을 담당하는 계층
- 뷰 : 출력을 담당하는 계층
- 모델 : 유저의 멘탈모델
모델과 프레젠테이션을 분리하여 유저의 멘탈모델과 컴퓨터 모델을 일치시키는 것이 MVC의 본질
* 멘탈모델이란? 사용자가 목적을 달성하기 위해 수행하는 행동과 그 심리적 근거들을 분류하여 도식화한 것
유저의 멘탈모델
그렇다면 위의 나온 모든것들이 다 MVC인가?
- MVC는 View가 입력을 받는 개발환경도 있고, Controller가 입력을 받는 개발환경도 존재한다.
- 개발환경에 따른 역활의 차이보다 중요한 것은 유저가 애플리케이션이 해결하려는 문제에 대해서 유저의 멘탈 모델과 컴퓨터에서 구현한 모델이 대응 되도록 개발하자는 것이 MVC의 본질임을 이해하는 것이다.
- 아키텍처는 딱 하나의 정답이 있는 것이 아니다. -> 모든 아키텍처를 공부할 때, 깔고가야할 가장 중요한 베이스이다.
다양한 MVC
1) Controller가 View와 Model의 상태 변경에 모두 관여
컨트롤러가 사용자에게 입력을 받으면, 뷰에게 UI 갱신을 요청하고, 모델에게는 상태 변경 요청 -> 모델이 상태 변경 후 컨트롤러가 이벤트를 발행한다.
2) Controller는 요청만 전달 View가 Model의 상태 변경을 구독
컨트롤러가 사용자 입력을 받고 Model에게 상태 변경 요청-> 모델이 상태변경 후 View에게 이벤트 발행
3)View가 자신의 상태 변경후, 직접 모델에 상태 변경을 요청
컨트롤러가 사용자 입력을 받고 뷰에게 상태변경을 요청-> 뷰가 모델에게 상태변경 요청
위의 과정들을 다합친 것이 아래 사진과 같다.
MVC의 초기모델이며, 입/출력 방식에 대해 여러방면으로 해석되고 다듬어 졌다.
일반적으로 생각하는 MVC
- Model : 데이터와 비즈니스 기능을 처리하는 도메인 모델
- View : 모델이 가진 정보를 화면에 표현
- Controller : 사용자의 입력을 해석해서 적절한 로직으로 연결하는, 애플리케이션의 인터페이스 역할을 한다.
뷰와 모델사이에서 중개자 역할을 하는 고차원의 컨트롤러를 가정한다.
JSP Model1
-웹으로 부터 유저의 입력을 받으면 JSP파일에서 프레젠테이션 로직과 비즈니스 로직을 모두 처리하는 모델
JSP Model2
- Model1의 JSP가 너무 거대해져서 나온 Model2
- 컨트롤러인 서블릿이 모델과 뷰 사이를 중개
Cocoa MVC 와 그에 대한 오해
iOS에서 MVC를 논한다면, 거의 대부분 CocoaMVC이다.
요즘에는 다양한 아키텍처들이 등장하고, 서로 비교하면서 CocoaMVC가 상대적으로 많이 비교를 당하며, 쩌리 취급을 한다. 그러다보니 다소 과장되었다고 느껴지는 부분이 있어 짚고 넘어갈려한다.
흔히 CocoaMVC의 오해라고 많이 알려진 Massive View Controller에 대한 부분이다.
어떠한 학문을 책 한권 혹은 하나의 섹션에 모든걸 담는다고 한다면 상상도 못할 페이지 수를 가지게 될것이다. 그렇다면 들고다니기도, 읽기도 싫을 것이다. 하지만 우리는 그것을 보고 "책이 너무 Massvie해. 동영상으로 보는게 나아"라고 하지 않는다.
학문의 영역을 대학수학1, 대학수학2와 같이 섹션을 만들고 이를 목차를 통해 표현하고 연관된 내용끼리 묶어 나누는 것이 더 올바르다고 생각한다.
아키텍쳐는 단지 도구일뿐이며, 우리가 GUI어플리케이션을 만들면서 고려하는 부분을 큰 틀에서 가이드해주는 것이다.
아키텍처의 내부에도 D&C, SOLID, 디자인 패턴 등 고려해야할게 많다. 이러한 세세한 디테일들을 놓친다면 그 어떤 아키텍처를 사용하더라도 Massive해진다.
RxSwift + MVVM 조합이라고 할지 언정 Massive해지지 않는가?
이에 대해서는 다음에 자세히 글을 작성하겠다.
Cocoa MVC
애플의 CocoaMVC는 기존의 MVC(Smalltalk)에서 모델과 뷰가 Observer패턴으로 연결되어 있는 점이 모델과 뷰의 재사용성을 떨어트리고 있다 생각하여, Model과 View 사이의 의존관계를 끊어 컨트롤러가 비대해지더라도 모델과 뷰의 재사용성을 높인것이다.
그러나,
여기서 말하는 Controller가 UIViewController를 의미하지는 않는다. Apple가이드 라인에서도 Controller는 Model과 View계층간의 통신을 담당할 뿐 ViewController가 모든 것을 처리하지는 않는다고 설명한다.
Model-View-Controller
Model-View-Controller The Model-View-Controller design pattern (MVC) is quite old. Variations of it have been around at least since the early days of Smalltalk. It is a high-level pattern in that it concerns itself with the global architecture of an applic
developer.apple.com
해당 링크를 보면 ModelController와 ViewController의 역할과 존재를 확인 할 수 있다.
또한 Controller가 View의 LifeCycle을 관리하며 강한 결합이 되어 있어, 테스팅이 어렵다는 내용도 쉽게 볼 수 있다.
Controller가 UIViewController만을 의미하지 않기에 UIViewController에 비즈니스 로직을 작성하는 것 자체가 애플이 제시하는 가이드라인을 따르지 않은 결과라고 생각한다.
UIViewController는 View로 해석하는 것 이 더 올바르지만, UIView는 혼자서 화면에 표시될 수 가 없다. 즉 system이 출력을 위해 다루는 단위는 UIViewController이기 때문이다.
따라서, Cocoa MVC를 좀 더 정확하게 해석한다면, ViewController - ModelController-Model의 형태가 되는것이 더 적절하며, 이는 통상적으로 알고있는 MVC보다는 MVP에 가까운 형태가 된다.
'Architecture' 카테고리의 다른 글
| iOS(UIKit)에서의 Coordinator Pattern (0) | 2023.09.18 |
|---|---|
| iOS(UIKit)에서의 CleanArchitecture+MVVM 예시 뜯어보기 (0) | 2023.09.15 |
| MVVM in iOS (0) | 2023.09.04 |
| MVP (Model - View - Present) (0) | 2023.08.28 |
| 아키텍처(Architecture) (0) | 2023.08.13 |
