[아키텍처패턴][iOS] MVC 패턴

 

 

 

📚 MVC 패턴

 

 

디자인 패턴 중 가장 기본적인 패턴

 

Model - View - Controller 구조의 아키텍처 패턴

 

 

 

💡  일반적인 MVC 패턴

 

- Model ---------- 앱의 데이터와 비즈니스 로직 ( 주로 struct나 class )

- View ----------- 화면과 control를 스크린을 통해 보여주는 역할 ( 주로 UiKit 상속 )

- Controller ------ View와 Model을 잇는 역할 ( 주로 UiViewController 상속 ) 

 

View와 Model이 직접적으로 소통하는게 아니라 Controller를 통해 소통하게 된다.

 

즉, View는 Model의 데이터를 보여주고, Model을 데이터를 관리한다. 이를 Controller가 잇는것

 

 

 

💡  애플의 MVC 패턴

 

ViewController를 사용하기때문에 View와 Controlller를 합쳐 ViewController와 Model로 구분된다.

Controller가 View의 LifeCycle까지 관리하면서 Controller의 역할이 더 늘어났다.

하지만 View와 Model의 연결은 더 간편해졌다.

원래는 Controller를 거쳐 View에게 전달해야했는데 그냥 ViewController에게 전달하면 되니까.

 

결론은 애플의 MVC패턴은 View와 Controller를 결합한 것일 뿐

기본적인 MVC패턴과 큰 차이는 없다.

 

 

 

MVC 구조

📌 Model

Model은 앱의 데이터를 정의하고 비즈니스 로직을 포함한다.

View에 대해서는 모른다. 

구조체나 클래스로 구현되어있다.

 

사용예시 

 - Network Code : 네트워크 통신은 단일 클래스에서 사용하는 것이 좋다. HTTP 헤더, 응답 및 오류처리 등 모든 네트워크 코드를 추상화하여 구현한다.

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

 - Pasing Code : 네트워크 response를 parsing하는 JSON Codable 모델을 정의할 때 사용한다.

 - Constants :  상수를 모델로 정의하면 유용하다. StoryBoard 이름, 날짜 Formatter, 색상 등을 여러 곳에서 재사용할 수 있다.

 - Hepers와 extensions : 프로젝트에서 String 등의 기능 추가도 모델을 사용한다.

 

 

코드예시

Person 이라는 구조체를 정의했다.

이 코드에 View 또는 Controller에 관한 코드가 있나? 전혀 없다.

Model은 그냥 데이터만 관리한다.

 

 

📌 View

View는 사용자가 보는 화면을 그리며 사용자와 앱의 상호작용을 담당한다.

Model에 대해서는 모른다.

Model과 소통해서도 안되고, 어떠한 비즈니스 로직도 포함되면 안된다.

받은 데이터로 화면을 구성하는데에만 관심이 있기때문에, UI와 관련 없는 코드는 포함되지 않을수록 좋다.

 

 

사용예시

 - UILabel, UIButton, UIImage 등

 

 

코드예시

UIView를 상속하는 PersonView라는 CustomView를 정의했다.

여기서도 마찬가지로 Model 또는 Controller에 관한 코드는 전혀 없다.

 

 

📌 Controller

View와 Model 사이에서 관리(중개) 역할을 한다.

View로부터 사용자의 Action을 받아 Model에게 어떤 작업을 해야할지 알려주거나,

Model의 데이터 변화를 View에게 전달하여 View를 업데이트 해야 하는지를 알려준다.

 

Controller는 View와 Model을 참조를 통해 소유 할 수 있다.

그리고 1개의 Controller는 여러개의 View와 Model을 소유 할 수 있다.

그리고 이 참조를 통해서 해당 View 또는 해당 Model에 바로 접근할 수 있다.

 

예를들어서 Model의 Data가 변경되었으니까 View에게 이걸 바꿔야해 라고 할 수 있죠.

Model에게도 Action이 발생했는데 그럼 이 Data를 변경해야겠는데? 하고 바로 변경할 수도 있습니다.

이 로직이 모두 Controller안에 들어가 있습니다.

 

코드예시

UIViewController를 상속하는 PersonViewController를 생성했다.

 

여기서는 각각 1개의 Model, View를 person, personView 프로퍼티로 소유하고 있다.

그리고 각각 직접 접근해서 person 데이터를 이용하여 View를 업데이트하거나, View로 액션을 받아서 person 데이터를 수정하고 있다.

 

View나 Model이 서로 직접 소통하는게 아니라 Controller를 통해서 소통하고 있다.

 

 

 

💡 Model과 View가 Controller와 소통하기 

 

그럼 이번에는 반대로, View와 Model은 Controller를 소유하지 않았다.

그럼 Controller와 어떻게 소통하겠는가?

 

Model의 입장에서 보자.

우리는 View와 Controller를 모른다. 그냥 데이터를 관리할 뿐이다.

여기서 Controller 또는 View에 접근하는 코드는 없다.

그럼 데이터가 변경됐는데 Controller에게 이걸 어떻게 전달하겠는가?

 

몇 가지 방식이 있겠지만 기본적으로 Model은 Property Observer를 통해서 소통할 수 있다.

 

Controller안에 이런 코드가 있었다.

Controller 에서 프로퍼티를 정의할 때 Observer를 이용해서 데이터의 변화가 생겼다고 알려줄 수 있고, Controller에서 그 데이터를 가지고 View를 업데이트할 수 있게 된다. 

 

 

그럼 이제 View의 입장에서 본다면?

View도 Model과 Controller에 접근할 방법이 없다. 

그럼 어떻게 Controller에게 어떤 변화 또는 이벤트가 발생했다고 말해줄 수 있을까?

 

 

바로 @IBAction를 이용해서 Controller와 소통한다. 

뭔가 터치가 발생했어!(touchUpInside) 등등 액션 여부를 Controller에게 전달할 수 있다.

이렇게 어떤 이벤트가 발생한다면 Controller는 필요에 따라 Model의 데이터를 변경할 수 있도록 만들 수 있다.

 

이러한 구조로 인해서 Model과 View는 재사용성이 높아진다.

서로를 모르고 Controller도 참조하지 않기 때문에 다른 Controller에서 사용해도 괜찮다.

어디서든 사용이 가능하다는 것이다.

 

 

 

MVC 장단점

MVC 장점

- 생산성이 높고 쉽다

 

MVC는 각 구조의 역할이 명확하므로 역할을 분담하여 빠르게 구현할 수 있다.

다른 패턴에 비해 코드량이 적으며 많은 개발자에게 친숙하기 때문에 쉽게 접근, 유지보수 할 수 있다.

 

따라서 프로젝트 규모가 크지 않고, 특별한 패턴이 필요하지 않을 때 MVC를 사용하면 빠르고 쉽게 개발할 수 있다.

 

MVC 단점

- 테스트가 힘들고 Controller의 크기가 크다는 것 

 

Controller에 문제가 있는데, 로직이 특정된다는 것이다. 

조금 쉽게 설명을 하면, StoryBoard 하나의 scene의 대부분 하나의 UIViewController를 상속한다.

다른 Scene에서 이전에 사용하던 UIViewController를 상속하지 않는다.

왜냐면 다른 곳에서 재사용할 수 없을 정도로 그 Scene에 특화되어있기 때문이다.

 

이렇게 MVC패턴에서는 Controller를 재사용하지 않는다.

하지만 이 안에 사용되는 View 또한 Model들은 다른 UIViewController에서 재사용하는 경우는 흔하다. 

 

- 또 다른 MVC의 문제는 각 객체들이 각 카테고리에 딱 들어맞지 않는다는 것 

 

그래서 구현을 하다보년 Controller가 대부분을 담당하게 되면서 그 크기가 매우 커지게 된다.

심지어 iOS에서 사용하는 Controller의 이름이 ViewController ? 

 

즉, iOS에서 사용하는 MVC패턴은 View와 ViewController의 경계가 모호해지면서 화면에 출력하는 것까지 Controller가 담당하게 된다. 심지어 데이터까지 Controller에서 처리해버리는 상황도 발생한다. 

이렇게 되면서 Controller는 프로젝트가 진행될수록 점점 커지게 되고, Controller를 Test 하는것은 매우 힘든 작업이 된다.

테스트를 하려고 하면 대부분 View와 관련이 되어서 UnitTest를 해야 할지 UITest를 해야할지 헷갈리게 된다.

 

 

 

MVC를 지키며 개발하는 5가지 규칙

MVC를 지키며 개발하는 방법에 대해 알아보겠다.

 

1. Model은 Controller와 View에 의존하면 안된다.

          Model 내부에 View와 Controller와 관련된 코드가 없어야 한다.

2. View는 Model에만 의존하고 Controller를 의존하면 안된다.

          View 내부에 Model의 코드만 존재하고 Controller 코드는 존재하면 안된다.

3. View가 Model로부터 데이터를 받을 때는 사용자마다 다르게 보여줘야 하는 데이터만 받아야한다.

          Title 같은 공통 문구는 Model 에서 받지 않아야하고 사용자 이름, 닉네임처럼 사용자마다 다른 데이터만 Model로부터 받아야 한다.

4. Controller는 View와 Model에 의존해도 된다.

          Controller 내부에 Model과 View 코드가 존재해도 된다.

5. View가 Model로부터 데이터를 받을 때는 Controller를 통해 받아야 한다.

          Controller는 View와 Model을 중개하므로 View는 Controller로부터 Model의 데이터를 받아야 한다.

 

 

 

📌 MVC 실습

 

다음 블로그를 참고하였다.

 

 

https://jeong9216.tistory.com/478

[디자인패턴] MVC 패턴 with iOS