기존의 코드는 UI 컴포넌트 별로 분리를 하였기 때문에, 프레젠테이션 계층이 분리가 되어있지 않았다. 이러한 분리는 유저 멘탈모델과 컴퓨터의 모델 간의 괴리를 만들어 내었다. MVC는 유저 멘탈모델과 프레젠테이션을 분리하여 유저 멘탈모델과 컴튜퍼 모델을 일치시키고자 등장하였다.
에디터(Editor) : 프리젠테이션 계층을 담당
컨트롤러(Controller) : 입력 담당
뷰(View) : 출력 담당
모델(Model) : 유저 멘탈모델
유저 멘탈모델이란? 유저가 앱이 이렇게 되어있을꺼다 생각하는 것 즉 특정 주제에 대한 사용자의 행동 친화도를 하나의 모델로 정리한 것
SmallTalk MVC
옵저버 패턴으로 뷰가 모델의 변경을 감시
Model의 변화가 View에 영향을 끼치게되는 단점이 존재
입력장치로부터 신호를 받아 모델에 비지니스 로직을 처리하는 입력 컨트롤러(Input Controller)임
프레젠테이션의 상태와 로직을 표현할 공간이 없음
입력을 받을 때 조건별로 작동시키거나, 입력받은 내용을 확인하는 로직을 뷰에서 처리하게 되면서 뷰의 역할이 비대해지게 됨
Cocoa MVC
A goal of a well-designed MVC application should be to use as many objects as possible that are (theoretically, at least) reusable. In particular, view objects and model objects should be highly reusable. 좋은 MVC는 최대한 많은 객체가 재사용가능해야 한다. 특히 View와 Model객체는 높은 재사용성을 가져야한다. 이전의 MVC는 Model과 View가 옵저버 패턴으로 연결되어 있기 때문에, 모델의 재사용성을 떨어뜨리고 있다.
Model, View, Controller 세가지 유형의 객체로 역할을 분리
Model: 데이터를 캡슐화하고 데이터를 처리하는 로직을 담당
View: 사용자에게 정보를 제공
Controller: 모델을 뷰에 연결
View와 Model사이에 Controller를 두어 재사용성을 높임
이를 중개자 역할의 고차원 컨트롤러(Mediator Controller)로 인지
이로 인해 Controller가 비대해지더라도 재사용성을 높이는 것에 더 큰 의미를 둠
MVP의 Passive View와 유사
UIViewController, SwiftUI는 뷰의 표현력이 높기 때문에 프레젠테이션 모델을 사용하여 프레젠테이션 상태와 로직을 분리할 필요가 없음
iOS의 UIViewController
View와 Controller가 밀접한 관계를 갖기 때문에 Massive ViewController라는 인식이 있지만 ViewController의 책임만 지키면 비대해지지 않을 수 있음
UIViewController의 책임
데이터 변경 시 UI 갱신하는 책임 Updating the contents of the views, usually in response to changes to the underlying data
View를 통해 유저 입력을 처리하는 책임 Responding to user interactions with views
전반적인 인터페이스의 layout을 관장하는 책임 Resizing views and managing the layout of the overall interface
다른 객체들과 연계하는 책임 Coordinating with other objects - including other view controllers - in your app
UIViewController의 계층 분리
UIViewController는 뷰의 표현력이 높기 때문에, ViewController안에 ChildViewController를 상속시켜 코드 분리를 하여 별도의 계층을 생성하지 않을 수 있음
참고링크
SwiftUI의 경우 View자체가 state를 활용하여 UI와 바인딩할 수 있기 떄문에 별도의 ViewModel 없이 MV 형태의 개발도 이뤄짐
기존의 코드는 UI 컴포넌트 별로 분리를 하였기 때문에, 프레젠테이션 계층이 분리가 되어있지 않았다. 이러한 분리는 유저 멘탈모델과 컴퓨터의 모델 간의 괴리를 만들어 내었다. MVC는 유저 멘탈모델과 프레젠테이션을 분리하여 유저 멘탈모델과 컴튜퍼 모델을 일치시키고자 등장하였다. - 에디터(Editor) : 프리젠테이션 계층을 담당 - 컨트롤러(Controller) : 입력 담당 - 뷰(View) : 출력 담당 - 모델(Model) : 유저 멘탈모델
> 유저 멘탈모델이란? > 유저가 앱이 이렇게 되어있을꺼다 생각하는 것 > 즉 특정 주제에 대한 사용자의 행동 친화도를 하나의 모델로 정리한 것
- 옵저버 패턴으로 뷰가 모델의 변경을 감시 - Model의 변화가 View에 영향을 끼치게되는 단점이 존재 - 입력장치로부터 신호를 받아 모델에 비지니스 로직을 처리하는 입력 컨트롤러(Input Controller)임 - 프레젠테이션의 상태와 로직을 표현할 공간이 없음 - 입력을 받을 때 조건별로 작동시키거나, 입력받은 내용을 확인하는 로직을 뷰에서 처리하게 되면서 뷰의 역할이 비대해지게 됨
### Cocoa MVC > *A goal of a well-designed MVC application should be to use as many objects as possible that are (theoretically, at least) reusable. In particular, view objects and model objects should be highly reusable.*
좋은 MVC는 최대한 많은 객체가 재사용가능해야 한다. 특히 View와 Model객체는 높은 재사용성을 가져야한다. 이전의 MVC는 Model과 View가 옵저버 패턴으로 연결되어 있기 때문에, 모델의 재사용성을 떨어뜨리고 있다.
- Model, View, Controller 세가지 유형의 객체로 역할을 분리 - Model: 데이터를 캡슐화하고 데이터를 처리하는 로직을 담당 - View: 사용자에게 정보를 제공 - Controller: 모델을 뷰에 연결
- View와 Model사이에 Controller를 두어 재사용성을 높임 - 이를 중개자 역할의 고차원 컨트롤러(Mediator Controller)로 인지 - 이로 인해 Controller가 비대해지더라도 재사용성을 높이는 것에 더 큰 의미를 둠 - MVP의 Passive View와 유사 - UIViewController, SwiftUI는 뷰의 표현력이 높기 때문에 프레젠테이션 모델을 사용하여 프레젠테이션 상태와 로직을 분리할 필요가 없음
### iOS의 UIViewController - View와 Controller가 밀접한 관계를 갖기 때문에 Massive ViewController라는 인식이 있지만 ViewController의 책임만 지키면 비대해지지 않을 수 있음
**UIViewController의 책임** 1. 데이터 변경 시 UI 갱신하는 책임 > Updating the contents of the views, usually in response to changes to the underlying data 2. View를 통해 유저 입력을 처리하는 책임 > Responding to user interactions with views 3. 전반적인 인터페이스의 layout을 관장하는 책임 > Resizing views and managing the layout of the overall interface 4. 다른 객체들과 연계하는 책임 > Coordinating with other objects - including other view controllers - in your app
**UIViewController의 계층 분리** - UIViewController는 뷰의 표현력이 높기 때문에, ViewController안에 ChildViewController를 상속시켜 코드 분리를 하여 별도의 계층을 생성하지 않을 수 있음 > [참고링크](https://hyunsikwon.github.io/ios/iOS-ChildViewControllers/) - SwiftUI의 경우 View자체가 state를 활용하여 UI와 바인딩할 수 있기 떄문에 별도의 ViewModel 없이 MV 형태의 개발도 이뤄짐 - 계층 추가는 `불편함`이 기준이 되어야 함 - 계층 분리로 직관성이 떨어진다면 계층 분리를 재고해봐야함
