MVC패턴 이해하기

2 minute read

iOS개발을 통해 MVC 패턴 이해하기.

https://user-images.githubusercontent.com/70311145/110515080-572c8d80-814b-11eb-85b1-137caf771b1a.png

스크린샷 2021-03-10 오후 6 02 41


Controller to View: 인스턴스(Outlet)

Controller는 Outlet을 통해 View에게 말을 건다.

스크린샷 2021-03-10 오후 6 10 21

스크린샷 2021-03-10 오후 6 11 18

스토리보드에서 그려진 View를 컨트롤러로 당겨오면 IBOutlet이 생기게 되는데

이것이 바로 Controller가 View에게 말을 걸기 위해 해당 레이블이나 텍스트뷰의 인스턴스를 만드는 것!!

  • 스토리보드에서 코드로 드래그하면 View가 Controller에게 말거는거 아닌가??

    No!! IB는 Interface Builder의 약자로 IBOutlet을 통해 Controller는 View에게

    ‘너가 보여줄 이미지는 이거야~’, ‘너의 텍스트는 이거야~’등과 같이 구체적인 지시를 하게 됨 ㅇ_ㅇ

    스크린샷 2021-03-10 오후 6 26 19

    간단한 예로 Controller에서 ‘Label~너의 텍스트 컬러는 오렌지야!!’를 말해봄!!


View to Controller: IBAction

반대로 View가 Controller에게 말을 걸수도 있다.

감히 View 따위가 Controller한테??! 할 수 있겠지만 더 상위에 있는 유저가 View를 통해

메세지를 던질 수 있기 때문!! 이런 특수한 상황에서 제한적으로 View가 Controller에게

말을 걸 수 있는 두가지 방법을 제공한다.

  • 첫번째 방법

    Controller가 자신에게 Target(과녁)을 설정해놓고, View에게 그 Target에 쏠 화살(Action)들을

    건네주는 방법이 있다. 아주아주 중요한 내용!!

    Target-Action메커니즘이라고 부르며, 버튼을 사용할 때 흔히 볼 수 있다.

스크린샷 2021-03-10 오후 6 34 21

스크린샷 2021-03-10 오후 6 35 03

이번에는 버튼을 스토리보드에서 코드로 드래그해서 IBAction을 연결해 준다.

유저가 버튼을 터치하면 타이틀의 텍스트 색상이 그린으로 바뀌고 이 버튼이 Target-Action이다.

버튼이 눌려 Action이 발생하면 Controller의 changedTextColor()메서드가 Target으로서 대응하게 된다.

ezgif com-gif-maker

  • 두번째 방법

    View가 Controller에게 말을 거는 또 하나의 방법은 Delegation Protocol을 통한 방법이다.

    단순하게 생각해서 Controller 클래스 안에 View 클래스의 인스턴스를 만드는 IBOutlet처럼,

    View 클래스 안에 Controller 클래스 인스턴스를 만드는 것과 유사하다.

    다만 클래스 대신 프로토콜이 활용되는 것일 뿐!!

    Delegation은 View가 자신의 제어권을 Controller에게 위임하는 프로토콜로서

    앱을 사용하는 유저가 행동을 하는 경우에 대한 권환이 위임된다.

    Delegate Pattern에 대해 공부해야한다!!

    • will: ~하려는 순간
    • did: ~을 막 한 이후
    • should: ~을 하도록 하게 할 것인지
    • data at: 해당 View가 표시해야할 데이터가 무엇인지
    • count: 해당 View에 총 몇개의 데이터가 존재하는지

will, did, should는 delegate라고 칭하며 아래 두가지는 datasource delegate라고 부르기도 한다.


Controller to Model: 인스턴스

controller가 View에게 말을 걸기 위해 Outlet 인스턴스를 만들 듯이 Controller가 Model에게 말을

걸기 위해서는 Model 클래스의 인스턴스를 만들면 된다.


Model to Controller: Notification 및 KVO

Controller가 대빵이다!!(유저 제외하고,,ㅎ)라고 위에서부터 얘기해왔듯이

Model도 Controller에게 ‘내가 임마!!’하면서 바로 말을 걸 수는 없다,, 깨갱,,,

Model은 자신의 데이터가 변할 때와 같이 무엇인가 알려줄 필요가 있을때,

라디오 처럼 자신의 주파수에 맞춘 Controller 및 Model들에게 관련 안내를 하는 구조로 교신을 함.

Dictionary처럼 Key와 Value를 관찰하는 Key Value Observation(KVO)를 통해 수행되며

변경사항이 있을 경우 Notification(알림, 통지)이 가게 된다.

Notification과 KVO는 Observer행동 패턴에 속한다.

KVO링크

코코아디자인패턴


고민한 점

  • IBAction과 IBOutlet 앞에 붙는 @는 뭘 뜻하는 걸까?

    @는 컴파일러에게 어떤 속성을 가지고있다고 전하는 역할을 하는 예약어이다.

    @가 붙은 명령어에 대해 어떤 속성이 부여되었음을 의미.

    속성 (Attribute의 At과 @의 At이 같아서..?)

    @IBAction - Interface Builder와 연결된 Action.

    @UIApplicationMain - App의 Main이 여기에 있다.

    등 @가 붙은 다양한것들이 존재한다,,

  • MVC패턴 정말 괜찮은 패턴인데 왜 규모가 큰 프로젝트에서는 MVVM, MVP등을 사용하는걸까?

    무언가 단점이 있으니까 다른 패턴을 사용하지 않을까 생각이 들어서 단점을 알아보았다.

    • viewController와 같이 View와 Controller가 밀접하게 연결되어 있다.

      Controller가 View의 생명주기까지 관리하기 때문에 분리가 어렵다.

      그렇게되면 재사용성이 떨어지고, 유닛 테스트를 진행하기 힘들어진다.

      또 Controller에 코드가 밀집될 수 있다.

      생명주기, delegate, datasource, network, DB접근 등 많은 코드가 Controller에

      작성되면 그만큼 크기가 비대해지고 내부 구조는 복잡해지기 마련,,

      그렇게 되면 당연히 복잡해진 코드는 큰 규모의 프로젝트에서 치명적일 수 있어서

      유지보수 측면에서 다른 패턴들을 지향하는 것 같다.

Comments