MVC 구조에 대해 각 역할과 흐름을 설명하시오.

이하연·2021년 8월 15일
1

[Swift] 스위프트

목록 보기
10/27
post-thumbnail

디자인 패턴

정의

소프트웨어 공학의 소프트웨어 설계에서 공통으로 발생하는 문제에 대해 자주 쓰이는 설계 방법을 정리한 패턴이다.

프로그램이나 어떤 특정한 것을 개발하는 중에 발생했던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 "규약"을 통해 쉽게 쓸 수 있는 형태입니다.

사용 이유

개발의 효율성, 유지보수성, 운용성이 높아지며 프로그램의 최적화에 도움이 됩니다.

MVC 패턴이란?

  • 프로그래밍을 할 때 전체적인 구조에 관련된 여러 디자인 패턴 중 하나
  • model, view, controller의 약자인 MVC 패턴은 하나의 어플리케이션, 프로젝트를 구성할때 그 구성요소를 세가지의 역할로 구분한 디자인 패턴입니다.
  • 이 패턴을 성공적으로 사용시, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 독립적으로 유지보수를 할 수 있습니다.

M

  • Model

  • 프로그램이 작업하는 세계관의 요소들을 개념적으로 정의한 것

  • 프로그램이 목표하는 작업을 원활하게 수행하기 위해 필요한 물리적 개체, 규칙, 작업 등의 요소들을 구분하는역할

  • 앱의 데이터와 비즈니스 로직 가지고 있습니다.

  • 결과적으로 Model을 잘 설계한다라는 것은!

    → 해당 도메인 세계를 얼마만큼 이해하고 있는지와도 밀접한 연관이 있습니다.

    → 물리적인 요소뿐아니라 추상적인 요소 또한 해당 작업을 수행하는데 특정 책임과 역할로서 구분될 수 있다면 최대한 구체적이고 작은 entitiy를 유지하면서 Model 설계하는 것이 중요합니다.

  • DTO, DAO로 분류 - 생략

V

  • View
  • 사용자가 보는 화면에 입출력 과정 및 결과를 보여주기 위한 역할 ( UI 담당 )
  • 입출력의 순서나 데이터 양식은 Controller에 종속되어 결정됩니다. 이때 View는 도메인 모델의 상태를 변환하거나, 받아서 렌더링하는 역할을 합니다.
  • 객체를 전달받아 상태를 바로 출력하는 역할만을 담당해야 합니다.
  • view에서는 도메인 객체의 상태를 따로 저장하고 관리하는 클래스 변수나 인스턴스 변수가 필요 없습니다.

C

  • Controller
  • model과 view를 연결시켜주는 다리 역할
  • 도메인 객체들의 조합을 통해 프로그램의 작동 순서나 방식을 제어합니다.
  • view와 model이 각각 어떤 역할과 책임이 있는지 알고 있어야합니다.
  • View로부터 사용자의 action을 받아 Model에게 어떤 작업을 해야하는지 알려주거나 Model의 데이터 변화를 View에게 전달하여 View를 어떻게 업데이트할지 알려줍니다.
  • Model, View에게 직접 지시 가능

MVC 패턴 흐름

Controller는 Model, View에게 직접 지시할 수 있습니다.

하지만 Model,View는 독립되어야 하기에 서로 소통할 수 없고 Controller를 통해 소통이 진행됩니다.

그렇다면 어떻게 소통할 수 있을까?

Controller - Model

  • Controller는 Model에게 언제든지 이야기 할 수 있습니다.
    • 모델의 모든 것을 알고있고, 보내고 싶은 메시지를 보낼 수 있습니다.
  • Model은 Controller에게 이야기할 방법이 없습니다.
    • 이유는 컨트롤러는 UI로직을 다루는데 모델과 UI는 별개이기 때문입니다.
    • 하지만 UI와 상관없는 모델이 값이 바뀌는 데이터를 가지고 있다면 NotificationKVO 를 이용하여 컨트롤러와 소통할 수 있습니다.
    • 즉 이 또한 컨트롤러에게 직접 말하는 방식이 아닌 방송처럼 그들에게 전달해줍니다.

Controller - View

  • Controller와 View 연결은 대부분 Outlet을 통해 이루어집니다.
  • View와 Controller 역시 이야기할 필요가 있습니다.
    • 이유는 뷰는 컨트롤러의 하위종속자이고, UI안에서 일어나는 것들을 Controller에게 전달해야하기 때문입니다.
    • 따라서 뷰는 컨트롤러에게 이야기할때 눈에 보이지 않고 구조화되어야합니다.
      • 눈에 보이지 않는다는 건 뷰에 있는 객체는 자신이 어떤 클래스에게 이야기하고 있는지 모른다는 뜻
      • 구조화되어야 한다는 건 객체에 대해 아는 바가 없기에 제대로 미리 서술되어 있는 방식으로 의사소통 해야한다는 뜻
    • target-action
      • 컨트롤러가 @IBAction 코드로 메서드를 생성합니다(타겟).
      • 뷰의 하위종속자 객체가 컨트롤러가 생성한 타겟메서드와 연결하면 뷰가 컨트롤러와 이야기하고 싶을 때 간단하게 타겟메서드를 호출하면 됩니다.
      • 뷰로부터 컨트롤러로 보내지고 있는 액션은 보통 컨트롤 + 드래그로 연결합니다
    • delegate
      • 가끔 뷰는 단순히 터치되는 것 이상으로 더 복잡한 의사소통을 하기도 합니다.
      • 예를 들어 뷰의 하위종속자인 스크롤 뷰는 다양한 정보들을 컨트롤러에게 이야기합니다. 왜냐하면 컨트롤러는 그것에 대해 알고 반응해야 하고, 정보가 모델에 영향을 줄 수도 있기 때문입니다.
      • 따라서 주고받는 정보들이 많을 것이고, should, will, did 같은 말이 포함될 것입니다.
      • 뷰의 하위종속자들은 컨트롤러에게 다양한 질문을 하고 싶어하는데 should, will, did 같은 말이 포함된 질문들은 델리게이트라는 것을 통해 이뤄지게 됩니다.
        • delegate는 위임이라는 뜻인데, 뷰의 하위종속자들이 컨트롤러에게 어떤 책임을 위임하고 있기 때문에 이러한 단어를 사용합니다.
        • 델리게이트는 뷰 안에 있는 프로퍼티입니다.
    • datasource
      • 뷰는 자신이 보여주고 있는 데이터를 소유할 수 없습니다.
      • 뷰는 컨트롤러에게 매번 물어보고, 컨트롤러는 모델에서 데이터를 가지고 와서 표시합니다.
      • 이것은 델리게이트와 다른종류의 프로토콜입니다.
      • should, will, did 대신 다른 프로토콜의 메시지를 받습니다.
      • 뷰는 데이터에 대해 이곳에 있는 데이터를 달라고하거나, 데이터의 개수가 몇개인지 물어봐서 무슨 일이 생기고 있는지 알게되고, 그걸 화면에 보여줄 것입니다.
      • 이것 또한 델리게이션 과정으로 이루어지는데 여기서 쓰이는 델리게이트가 바로 데이터소스입니다.

0개의 댓글