❗️LikeLion 멘토링을 진행하며 평소에 궁금했던 디자인패턴에 대해 토론하고 학습할 수 있는 기회가 있어 학습 후에 간단하게 정리해보겠다! 틀린 정보나 좋은 정보를 가지고 계시다면 댓글 부탁드림니다..🙏
개요 👈
평소 기업들에서 보면 사용하는 기술이나 우대 조건에 항상 MVVM 이라고 적혀있어 도대체 그게 뭐지?!! 라는 생각으로 멘토님에게 질문하게 되었다!
그래서 학습한 결과 개발에 있어 큰 틀이 있다는 것을 깨닫게 되었다....
바로 개발에는 아키텍쳐가 중요하다는 것!
아키텍쳐가 없다면 프로젝트가 커졌을 때 디버깅이 힘들어지고, 오류를 발견하기도 힘들어진다.
그래서 먼저 좋은 아키텍쳐가 프로젝트에 있어서 얼마나 중요한지 알게 되고, 좋은 아키텍처의 중요성에 대해 학습했다.
1. 객체들의 역할이 분명한가? (Balanced distribution of responsibilities among entities with strict roles)
2. 테스트하기 용이한가? (Testability usually comes from the first feature)
3. 사용성이 편리하고 유지보수 비용이 낮은가? (Ease of use and a low maintenance cost)
기본적인 아키텍쳐의 시작은 좋은 아키텍쳐이고,
기준에 부합하기 위해 iOS에서는 Model, View, Controller 이렇게 세 가지 카테고리로 분할한 패턴이 나오게 된것!
그리고 Apple이 UIKit을 MVC패턴을 기반으로 사용하게 된 것이다.
물론 마지막에도 적겠지만 각 패턴의 장점과 단점은 각각 가지고 있고,
결론은 프로젝트의 성격에 맞는 아키텍쳐를 선택하고 좋은 코드를 구현하기 위해 노력해야 한다는 점!
이제 개요를 마치고(줄인다고 줄였는데..) 본격적인 디자인 패턴 분석에 들어가보겠다.
MVC 패턴
[ 로직 구성도]
View : 화면에 보여지는 UI
Model : 데이터를 다루는 부분
Controller : 위의 Model과 View를 이어주는 역할
[동작 원리]
1. Conroller로 사용자의 입력이 들어온다.
2. Controller는 Model을 입력에 맞춰 update.
3. Model은 해당 데이터를 보여줄 View를 선택해서 화면에 보여주게 된다.
[장점]
1. 규모가 작은 프로젝트에서 사용하기에 좋은 패턴
2. 다른 디자인 패턴은 Model, View, Controller 외에 추가해야 할 것들이 많다!
[단점]
1. 모든 로직을 다 Controller에 구성했기 때문에 프로젝트가 커지면 Controller 또한 커진다.
2. 그렇게 되면 서로 독립성이 없어지고, 테스트하기 어렵고, 재사용성이 떨어지게 된다!
-> 좋은 아키텍처의 특징 중 객체들의 역할이 분명해야 한다는 조건에 어긋나는 구조!
또한 서로 독립성이 없기 때문에, 재사용성 또한 떨어진다.
Apple의 MVC 패턴
Apple의 CocoaMVC 패턴은 이러한 단점을 극복하고자 새로운 패턴을 제시한다.
[ 로직 구성도 ]
목적: Controller가 View와 Model의 중재자 역할을 해 View와 Model에 독립성을 부여하기 위함.
간단하게 말하면, 컨트롤러가 뷰와 모델을 연결시켜주어서 서로 분리되어 있고 서로에 대해 알 필요가 없게끔 만들려고 함.
❗️하지만 Controller가 View를 관리하기 때문에 View와 Controller를 분리하지 못해 독립성을 확보하지 못한다..
ViewController는 온전히 MVC의 Controller 역할만 하는게 아니기 때문.(View에 대한 설정, 수정 등 코드를 가지고 있다!)
-> Model은 분리해서 테스트할 수 있지만, View와 Controller는 서로 강하게 연결되어 있어 테스트하기 힘들어진다!
MVP 패턴
기존의 Controller를 제거하고 Presenter로 구성했다.(Apple의 Cocoa MVC패턴과 비슷한 구조)
[ 로직 구성도 ]
View : 화면에 보여지는 UI
Model : 데이터 및 데이터 조작 로직 구성
Presenter : View에서 요청한 Model의 정보를 가져와 가공 후 View의 데이터와 상태를 update 해주는 역할
❗️이를 통해 View와 Model은 서로를 알 필요가 없어진다.
[동작 원리]
1. View로 사용자의 입력이 들어온다.
2. View는 Presenter에게 작업을 요청한다.
3. Presenter에서 필요한 데이터를 Model에 요청한다.
4. Model은 Presenter에 필요한 데이터를 응답한다.
5. Presenter는 View에 데이터를 응답한다.
6. View는 Presenter로부터 받은 데이터로 화면을 보여준다.
[장점]
1. 대부분의 책임을 Presenter와 Model이 가지고 있고 View는 출력만 하는 역할을 한다.
2. View에 대한 책임이 분리되어 있기에 각 요소들을 독립적으로 테스트할 수 있다.
[단점]
1. MVC에 비해 코드가 더 늘어난다.
2. View와 Presenter가 1:1 관계
MVVM 패턴
MVC의 View와 Controller 사이의 의존성이 높다는 문제를 해결하기 위해 나오게 되었다.
ViewController를 View로 보고, 기존 MVC 패턴의 Controller의 로직은 ViewModel로 옮긴다!
[ 로직 구성도 ]
View : 화면에 보여지는 UI (MVVM 패턴에서는 ViewController를 View로 간주한다)
Model : 데이터를 다루는 부분
ViewModel : Model이 얻어 온 데이터를 View에 맞게 가공해준다. Model이 변경되면 자동으로 View도 변경될 수 있도록 데이터 바인딩을 해준다.(데이터 일관성 유지)
✅ 이제 View와 Controller를 분리했으므로 독립성을 유지할 수 있게 된다. -> 독립적으로 테스트가 가능해진다!
[동작 원리]
1. View에 입력이 들어오면 ViewModel에 명령을 한다.
2. ViewModel은 필요한 데이터를 Model에 요청한다.
3. Model은 ViewModel에 필요한 데이터를 응답한다.
4. ViewModel은 응답 받은 데이터를 가공해서 저장한다.
5. View는 ViewModel과의 Data Binding으로 인해 자동으로 데이터가 갱신된다.
[장점]
1. View와 Model이 서로 전혀 알지 못하기에 독립성 유지
2. 독립성을 바탕으로 효율적인 테스트 가능
[단점]
1. 간단한 UI는 오히려 설계하기 어려워 힘들다.
2. 데이터 바인딩이 필수적으로 요구
3. 복잡해질수록 Controller처럼 거대해진다.
👉 기존의 UIKit은 MVC 패턴 기반이지만, SwiftUI는 MVVM 패턴을 기반으로 하기때문에 MVC -> MVVM 패턴으로 넘어가는 추세!
결론 🧑💻
각 디자인 패턴은 각각의 장단점이 존재하고, 무조건 좋다! 이렇게 해야한다! 보다는 본인이 하고자하는 프로젝트에 맞춰 올바른 디자인 패턴을 고른다면 효율적인 업무가 가능할 것 같다!
[참조]
MVC : https://leemyungjic.tistory.com/24 , https://jiyeonlab.tistory.com/38
MVVM : https://leemyungjic.tistory.com/24 , https://42kchoi.tistory.com/292
