[Swift] MVC Pattern

MVC Pattern

 

✅ MVC Pattern

 

(참고) 아래의 글을 직접 해석하고 이해를 바탕으로 작성하였습니다. (오역이 있을 수도 있습니다.)

https://www.raywenderlich.com/books/design-patterns-by-tutorials/v3.0/chapters/3-model-view-controller-pattern

Design Patterns by Tutorials, Chapter 3: Model-View-Controller Pattern

 

✅ MVC란?

MVC pattern

 

 

🟠 Model : 데이터가 있는 곳으로 지속적인 데이터, 모델 오브젝트, 데이터 parser, 매니저들, 네트워킹 코드들이 이곳에 위치합니다.

 -> 앱의 데이터를 보유하며, 일반적으로 구조체나 단순 클래스이다.

🟠 View : 앱에서 유저에게 보이는 계층입니다. 비지니스 로직을 포함하고 있지 않기 때문에 재사용 될 수도 있습니다.

 -> 화면에 시각적 요소와 컨트롤을 표시한다. 일반적으로 UIView의 하위 클래스이다.

🟠 Controller : delegation Pattern을 통해서 view와 Model 사이를 중재한다. 이상적인 시나리오에서는 Controller entity는 구체적으로 view에 대해서 알지 못한다. 대신에 protocol을 통해서 추상화하여 view와 소통한다. 

(가장 전형적인 예제로는 UITableView에서 UITableViewDataSource를 통해서 소통한다.)

 -> 일반적으로 UIViewController의 하위 클래스이다.

 

 

MVC 패턴은 애플이 UIKit에서 채택하기로 한 디자인 패턴이라 iOS프로그래밍에서 일반적이다.

컨트롤러들은 그들의 모델과 뷰에 strong propertis를 갖는것을 허용할 수 있어서, 직접 접근할 수도 있다. 컨트롤러들은 둘 이상의 model과 view를 갖고 있을수도 있다.

 

반대로! 모델과 뷰는 자신의 컨트롤러에 대해서 strong reference(강한 참조)를 하면 안된다. 이것은 retain cycle을 야기한다.

 

대신에 models은 properties를 observing하여 소통하며, view는 IBActions을 통해 통신한다.

 

이를 통해 models과 views를 재사용할 수 있습니다.

 

(참고) 뷰는 자신을 소유하고 있는 컨트롤러에 대해서 delegate를 통해 weak reference를 들고 있을 수 있다. (delegation pattern을 통해 확인할 수 있다.) 예를 들면 UITableView의 경우에는 weak reference를 통해서 delegate와 dataSource로 들고 있을 수 있다. 하지만 테이블 뷰는 자신의 컨트롤러에 대해서 알지 못합니다. 

 

 

✅ When should you use it?

 

iOS 앱 생성의 시작점으로 이용하자!!

거의 모든 앱에서 MVC외에 다른 패턴들이 필요할 수 있어서 다른 패턴을 추가해도 된다.

 

 

 

✅ Playground example

 

아래는 코드이다.

MVC패턴은 정말 대표적인 패턴이라 특별히 어려운 점은 없었다.

 

https://github.com/lgvv/DesignPattern/tree/main/model-view-controller-pattern/RabbleWabble

GitHub - lgvv/DesignPattern: ✨ 디자인 패턴을 공부합니다!

 

위의 파일에 대한 Class Diagram

 

가장 스탠다드하게 그린 클래스 다이어그램

 

(추가자료) 

아래는 raywenderlich의 다른 글을 기반으로 작성한 글입니다.

https://www.raywenderlich.com/1000705-model-view-controller-mvc-in-ios-a-modern-approach

Model-View-Controller (MVC) in iOS – A Modern Approach

 

MVC를 절대 깨서는 안되는 엄격한 규칙으로 접근하는게 아니라, 하나의 패턴으로서 취급하는 방법으로 공부하자.

 

✅ The Model(M)

모델은 앱의 데이터들을 포괄하고 있으며, 다른 클래스나 프로젝트의 객체도 모델에서 포함할 수 있다.

 

 - Network Code : 네트워크 통신은 단일 클래스에서 사용하는 것이 좋으며, HTTP 헤더, 응답 및 오류 처리 등 모든 네트워킹 요청에 공통되는 개념을 추상화할 수 있도록 함

 - Persistence Code : 데이터베이스, 코어 데이터, 디바이스 데이터를 저장할 때 사용하자

 - Parsing Code : 네트워크 응답에 대해서 parsing하는 것을 모델에 포함하자. JSON 인코딩/디코딩을 통해 파싱을 처리한다. 이렇게 할 경우 모델 객체의 세부사항을 알 필요가 없어서 비즈니스 로직과 parsing을 모델에서 처리합니다.

 - Managers and abstraction layers/classes : 모두가 사용하고, 필요로하며 그러나 그 누구도 무엇이라고 불러야할지 모릅니다. Mangers가 다른 클래스간에 접착제 역할을 하기도 합니다. 또한 하위 수준을 래핑하여 iOS 키체인, HealthKit과 함께 작업할 수도 있습니다.

 - Data sources and delegates : 모델 객체에 의존하는 것이 개발자들에게 덜 흔한 방법이다. 비즈니스 로직은 모델에서 처리하자고 이야기를 하였으나, 대부분의 경우에 개발자들은 컨트롤러에서 구현합니다.

 - Constants : 상수를 모델에 가지면 스토리보드 이름, 날짜 포맷터, 색상 등을 재사용 할 수 있다.

 - Helpers and extensions : 프로젝트에서 문자열 모음 등의 기능을 추가하는 것도 이 역시 모델의 일부로 간주된다.

 

포함할 수 있는 더 많은 케이스가 있지만, 위에 것들이 가장 흔한 예시이다.

테스트 관점에서 모델을 가장 좋은 후보인데, 비즈니스 로직, 네트워킹, persistence 메소드 등을 중요한 부분을 중심으로 테스트를 추가할 수 있다.

 

 

✅ The View(V)

사용자가 앱과 상호 작용할 때 인터랙팅하는 부분이다. 어떠한 비즈니스 로직도 포함되면 안된다.

 

일반적으로 View에서 code smell이 여러 형태로 발견된다. UI를 구성하기 위해, 네트워크나 비즈니스 로직 모델을 조정하는 등이 나타나는데 그렇지 않도록 주의하자.

 

View를 구성하는데 체크리스트로 사용하자. ( 모두 no로 대답할 수 있도록 )  

  - 모델 레이어와 소통하고 있는가?
  - 비지니스 로직을 포함하였는가?
  - UI와 관련하지 않은 것들이 있는가?

 

✅ The Controller(C)

컨트롤러는 domain-specific rules을 갖는 경우가 많아서 앱에서 거의 재사용할 수 없다.

 

일반적으로 아래 동작을 결정하는 것들은 controller로 볼 수 있다.

 - 지속성 또는 네트워크 중 어떤것을 먼저 엑세스 해야 하는가?

 - 얼마나 자주 앱을 새로고침 해야 할까?

 - 다음 화면은 어떤 상황이어야 할까?

 - 앱이 백그라운드로 가면 뭘 정리해야 할까?

 - 사용자가 셀을 눌렀는데 다음에는 어떻게 해야 할까?

 

컨트롤러 계층은 앱의 두뇌 또는 엔진으로 생각하며, 다음에 어떤 일이 일어날지 결정하자.

대부분의 경우 컨트롤러 계층에서 작업 시작, 데이터 로드 트리거, UI 상호 작용 처리, UI와 모델 사이의 데이터 조정 때문에 테스트를 수행하지 않을 수도 있다.

 

 

 

(참고)

애플의 MVC 패턴에 대한 문서

https://developer.apple.com/library/archive/documentation/General/Conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html

Model-View-Controller

 

delegation pattern

2022.04.10 - [iOS/DesignPattern] - [Swift] Delegation Pattern

[Swift] Delegation Pattern