MVC 패턴이란?

Model - View - Controller 의 약자로,
하나의 애플리케이션을 위 세 가지의 구성 요소로 구분한 패턴입니다.

💡 MVC의 의존성
Controller는 View와 Model에 의존할 수 있다
View는 Model 에 의존할 수 있다
Model은 View와 Controller에 의존할 수 없다

Model

Model은 데이터 정보 및 비즈니스 로직을 담당합니다. 데이터와 관련된 부분을 담당하며, 값과 기능을 가집니다.

- 애플리케이션이 무엇을 할 것인지 정의한다
- 애플리케이션이 가지고 있어야 할 데이터를 정의한다
- 데이터와 데이터를 처리하기 위한 로직이 있고, 결과물을 controller로 반환한다

즉, 비즈니스 로직, DB와 상호 작용, 데이터 가공 역할을 합니다

사용자가 편집하길 원하는 모든 데이터를 가져야 한다
View나 Controller에 대해서 어떤 정보도 알지 말아야 한다

View

View는 화면에 무엇인가를 보여 주는 역할을 합니다. 사용자 인터페이스 요소로, Model의 데이터를 사용자에게 시각적으로 보여 줍니다.

즉, 사용자의 입/출력을 시각적으로 보여 주는 UI로직 역할을 합니다

Model이 가지고 있는 정보를 따로 저장해서는 안 된다
Controller를 알 필요가 없다

Controller

Controller는 Model과 View의 중간 다리 역할을 합니다. 둘 사이에서 데이터 흐름을 제어하며, Model과 View의 역할을 분리합니다.

Model이나 View에 대해서 알고 있어야 한다
Model이나 View의 변경을 모니터링 해야 한다

이렇게 글로만 보면 감이 안 잡힐 수 있으니 간단히 예시를 들어 볼까요? 🔥

---

Lotto 예시 🙃

사용자가 구입 금액을 입력하면, 그에 따라 로또를 발행해 주는 프로그램을 구성한다고 해 봅시다!!

View는 해당 프로그램에서 무슨 역할을 할 수 있을까요?
사용자의 입력을 받고, 발행된 로또 결과를 사용자에게 보여 주는 역할을 할 수 있겠죠
❌ 다만, 로또가 어떻게 발행됐는지? 에 대해서는 알면 안 됩니다 ❌

그럼 비즈니스 로직과 데이터를 관리하는 Model은 프로그램에서 어떤 역할을 해야 할까요 🤔
로또 발행 프로그램의 핵심 비즈니스 로직에 대해 생각해 봅시다

1. 구입 금액에 따른 로또 구입 가능 개수를 계산한다
2. 로또를 발행한다

저는 이렇게 두 가지로 분류할 수 있을 것 같아요
다만, 사용자에게 입력이 어떻게 받아졌는지, 어떤 형식으로 받았는지, 발행한 로또가 어디에 쓰이는지에 대해서는 알면 안 되겠죠?

마지막으로 Controller의 역할은 무엇일까요?
View와 Model의 중간다리 역할을 하면 됩니다

1. View가 받아 준 사용자 입력을 받아서, Model에게 던진다
2. Model에서 계산한 구입 가능한 로또 개수를 받아, Model에게 해당 개수만큼 로또를 발행하라고 메시지를 던진다
3. Model에서 발행한 로또를 받아, View에게 던진다

---

이제 Model, View, Controller가 각각 어떤 역할을 하는지 감이 잡혔을 것 같아요 😎

그럼 이 패턴을 왜 사용해야 할까요?

MVC 패턴을 왜 사용하나요?

MVC 패턴을 이용하면, 각각의 구성 요소의 관심사를 분리할 수 있게 됩니다 ! 🥸

화면의 변경 -> 뷰를 수정
데이터나 비즈니스 요건의 변경 -> 모델을 수정
뷰와 모델 변경에 따른 컨트롤러 수정

관심사를 분리한다는 것은, 역할을 분리한다는 것과 같은 말입니다
즉, 서로 간의 결합도를 낮출 수 있겠죠?

또한 논리적으로 관련이 있는 기능을 하나로 묶으면서 높은 응집도를 유지할 수 있게 됩니다

---

Model? Domain Model?

개인적으로 MVC 패턴과 Domain의 관계에 대해 공부하면서 모델이라는 표현이 참 헷갈렸습니다...

💡 Domain : 컴퓨터 프로그램이 대상으로 하는 특정 주제 영역
공식적으로는 특정 프로젝트의 목표가 되는 주제

MVC 패턴에서의 모델

- 데이터와 관련된 모든 로직을 담당하는 계층
- 비즈니스 로직을 포함하기도 하지만, 단순한 데이터 구조일 수도 있음
- domain, repository, dto 등의 하위 패키지가 존재할 수 있음

도메인 중심 설계(DDD) 에서의 모델 (도메인 모델)

- 도메인 로직을 표현하는 객체와 개념의 집합
- 단순히 데이터 저장소의 구조가 아니라, 비즈니스 로직을 포함하는 객체
- domain.model 패키지에 위치함
- 데이터 저장 뿐만 아니라 비즈니스 규착을 캡슐화하여 도메인 논리를 책임짐

Model의 정의는 문맥에 따라서 달라지고, 데이터 뿐만 아니라 비즈니스 로직을 담당하는 넓은 의미를 가지고 있다고 합니다 😵‍💫

만약 Blackjack이라는 도메인을 갖는 프로젝트에서는 Card, Deck, Player 등이 도메인 모델이 될 수 있겠죠

MVC 패턴의 관점으로 보면 model이라는 패키지 안에 Card, Deck, Player라는 도메인이 존재할 것입니다

무엇을 중점에 두고 보느냐에 따라 관점이 달라질 것 같네요 🙃