TIL

🌱 난 오늘 무엇을 공부했을까?

📌 MVC

📍 MVC란?

• Model-View-Controller(model–view–controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다.

• 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들기 위함.

• MVC에서 Model은 애플리케이션의 정보(데이터)를 나타내며, View는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, Controller는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

📍 구성요소

1. Model

• Model(model)이란 어떠한 동작을 수행하는 코드를 말한다.

• 표시 형식에 의존하지 않는다.

• 사용자에게 어떻게 보일지에 대해 신경쓰지 않아도 된다.

• Model은 순수하게 public 함수로만 이루어진다.

• 몇몇 함수들은 사용자의 질의(query)에 대해 상태 정보를 제공하고 나머지 함수들은 상태를 수정한다.

• 요약
  - Model의 상태에 변화가 있을 때 Controller와 View에 이를 통보
  - Controller는 Model의 변화에 따른 적용 가능한 명령을 추가·제거·수정할 수 있다.
  - MVC 구현에서는 통보 대신 View나 Controller가 직접 Model의 상태를 읽어 오기도 한다.
  
  

2. View

• View는 보여줄 값(Model)을 Controller로부터 받아와 사용자에게 보여준다.

• 요약
  - 사용자가 볼 결과물을 생성하기 위해 Model로부터 정보를 얻어 온다.
  
  

3. Controller

• MVC의 View는 여러 개의 Controller(controller)를 가지고 있다. 사용자는 Controller를 사용하여 Model의 상태를 바꾼다.

• Controller는 Model의 mutator 함수를 호출하여 상태를 바꾼다.

• 이때 Model의 상태가 바뀌면 Model은 등록된 View에 자신의 상태가 바뀌었다는 것을 알리고 View는 거기에 맞게 사용자에게 Model의 상태를 보여 준다.

• 요약
  • Model에 명령을 보냄으로써 Model의 상태를 변경
  • View에 명령을 보냄으로써 Model의 표시 방법 변경

MVC 패턴을 안전하게 활용할 수 있도록 돕는 원칙

1. Model은 Controller와 View에 의존해서는 안된다.
   - Model이 Controller, View의 책임을 가지면 안 된다는 것이다. 각 레이어에서 담당하는 책임이라는 것이 존재한다.
   - 오로지 데이터에 대한 순수 로직 만 존재하는 것이 바람직하다.
   
   
2. View는 model에만 의존한다.
   - 여기서의 의존은 코드의 의존이 아니라 순수 도메인 데이터에 대한 의존이다.
   - view에서 사용되는 값은 Model에서 전달된 값이어야 한다. Controller가 Model에 대한 값을 View로 넘겨준다.
   
   
3. View는 Model로부터 사용자마다 다르게 변경되는 데이터만 받아야 한다.
   - 사용자마다 다른 생애주기를 가진 data만을 Model은 받아야 한다.
   - 공통된 정보에 대해서는 자체적으로 View가 소유해야 한다.
   - 공통으로 처리되는 부분에 대해서는 View자체에서 처리되어야 한다.
   
   
4. Controller는 Model과 View에 의존해야 한다.
   - Controller가 Model과 View에 대한 코드를 활용해도 된다
   
   
5. View가 Model로부터 데이터를 받을 때는 Controller에서 받아야 한다
   - Controller는 요청에 맞는 서비스를 호출하고 그에 로직이 처리된 Model의 결과를 View로 전달해야 한다.
   
   

   Components of a Layered Architecture

   1. 프레젠테이션 계층 – 사용자 또는 다른 시스템의 정보를 표시하고 명령을 캡처하는 역할을 한다.

2. 애플리케이션/비즈니스 계층 – 시스템이 제공해야 하는 동작을 정의하고 해당 도메인 개체가 해당 동작을 실행하도록 지시합니다. 이 계층은 일반적으로 전체 비즈니스 기능을 구성하는 서로 다른 도메인 개체의 동작을 조정하기만 하면 씬 유지됩니다. 이 계층에는 시스템 상황을 반영하는 상태가 없지만 비즈니스 기능의 진행 상황을 반영하는 상태를 유지할 수 있다.

3. 도메인 계층 – 알고리즘 및 프로그래밍 구성 요소를 담당합니다. 비즈니스의 개념, 시스템 상황 및 비즈니스 규칙에 대한 정보를 나타냅니다. 비즈니스 상태는 여기에서 제어되고 사용되지만 저장에 대한 기술적 세부 사항은 인프라 계층에 위임됩니다. MVC 용어로 이것은 Model이다.
   예)미국 달러 환율을 얼마로 할 것인가. 계산 공식은 얼마로 할 것인지 결정하는 코드. -> 도메인 로직

4. 인프라/지속성/데이터베이스 계층 – 데이터, 데이터베이스 처리를 담당한다.

📍 Cocoa MVC

🔗 MVC 객체의 역할과 관계

• Model 개체는 데이터 및 기본 동작을 캡슐화한다.

• 사용자에게 정보를 제공하는 객체 View

• Controller 객체는 Model을 View에 연결한다.

🔗 MVC 애플리케이션을 위한 디자인 지침

• View 클래스는 Model 클래스에 의존해서는 안됨(일부 사용자 지정 View에서는 불가피할 수 있음).

• View 클래스는 중재 Controller 클래스에 의존할 필요가 없다.

• Model 클래스는 다른 Model 클래스에 의존해서는 안됨.

• 중재 Controller 클래스는 Model 클래스에 종속되어서는 안됨(비록 보기와 마찬가지로 사용자 지정 Controller 클래스인 경우 필요할 수 있음).

• 중재 Controller 클래스는 View 클래스나 조정 Controller 클래스에 의존해서는 안됨.

• 조정 Controller 클래스는 모든 MVC 역할 유형의 클래스에 따라 다름.

🔗 이점

• 재사용 가능성이 높고 인터페이스가 더 잘 정의되는 경향이 있다.

• MVC를 기반으로 하지 않는 프로그램보다 쉽게 확장할 수 있다.

위키백과
우아한-테크-MVC-리View-레이어-MVC-패턴-5레이어
MVC-Apple