MVC:
모델이 뷰를 아는 상황에서는 '뷰와 모델이 분리되어있지 않으므로(의존성이 존재하므로) 재사용성이 떨어진다' 정도를 의미. 뷰와 모델이 직접 통신하지 않는다. 뷰는 뷰컨트롤러에게 델리게이트 디자인 패턴을 통해 뷰가 뷰컨을 모르게한다. 의존성 역전원칙을 통해 뷰가 뷰컨을 직접적으로 알지못하게 하고 오직 프로토콜만을 알고있게 하는것. View에서 VC로 델리게이트 패턴을 통해서 이벤트 전달. 모델 객체는 뷰 객체와 명시적으로 연결되어있어서는 안된다.
MVC 한계: 뷰와 컨트롤러가 너무 밀접하다. ViewController는 Controller, View life cycle에 관여. 따라서 모델은 분리하여 테스트하여도 View와 Controller는 강하게 연결되어 있어 테스트하기 어렵다. 또한 뷰와 모델에 맞지 않는 모든 비즈니스 로직이 Controller에 들어가게 된다. 예를들면 서버에서 받아온 데이터를 가공(포매팅)해서 뷰에 넘겨주는 로직이나 사용자로부터 들어온 interaction을 처리하여 모델/뷰에 넘기는 로직 등, 화면에 보이는 것과 데이터 이외에는 모두 ViewController가 처리하게 된다.
정답이 있는 디자인패턴은 없다.
MVC 패턴을 적용했을 때 ViewController가 너무 비대해진다면 해당 ViewController를 단일책임원칙(SRP)에 따라 여러개의 ViewController로 나누기.
엠브피 모델에서 비즈니스로직다룬다.
뷰컨은 뷰에 outlet등으로 view를 알고있다.
뷰는 뷰컨을 모르만 delegate패턴으로 view에서 어떤 method가 실행될때(예를들면 tableview관련..) ViewController가 이를 대신한다. 뷰는 뷰컨을 모르지만, 간접적으로 알 수 있는것.
뷰에서 델리게이트로 뷰컨에 요청
뷰에서 데이터소스 뷰컨에 요청
애플에서 기본적으로 지원하는 패턴이므로 쉽게 접근
뷰와 뷰컨이 너무 가깝다 재사용이어렵다 유닛테스트 어렵다
모델만 테스트가능
코드양 자체는 적어진다
MVVM
mvvm에서 viewmodel에 데이터처리하도록 하여 테스트케이스 만들때 viewmodel을 하는게 편하다 viewcontroller보다. viewmodel은 도 상속도 받지않으므로.
viewController는 view관련 코드만 있으므로 버그도 발생하지 않는다 잘.
The Model doesn’t know any other layer.
viewmodel에서 데이터를 in a View-friendly way 하게 바꾼다.
- 가져올때는 API에서 나타낸 DTO가져온다.
- 그러나 아래와 같이 TableView에서 쓰일때는 필요한 property만 제공.
