Spring Boot 또는 Spring 을 사용하고 있는 개발자 라면 MVC 패턴에 대해서 이야기를 종종 들어 봤을 것 이다.

그렇다면 누군가가 "MVC 패턴이 뭐에요?" 라고 질문을 했을때 상대방의 이해를 이끌어낼 수 있을 정도의 답변이 가능 하냐 라고 묻는 다면 부끄럽지만 대답 못할 것 같다.

따라서 이때 까지 당연하게 사용했던 MVC 패턴에 대해서 간단하게 한번 정리를 해보면서 이번 게시글을 작성 해 보려 한다.

🐢 MVC 패턴

MVC 패턴(Model-View-Controller 패턴)은 소프트웨어 개발에서 사용되는 디자인 패턴 중 하나로, 애플리케이션의 로직을 세 가지 역할로 나눠 관리하는 방법이다.

MVC 패턴은 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller)의 세 부분으로 구분한다.

📌 모델(Model)

1. 애플리케이션의 비즈니스 로직과 데이터를 담당
2. 데이터의 상태를 유지하고, 데이터의 유효성 검사, 조작 등을 수행
3. 주로 데이터베이스나 외부 서비스와의 상호작용을 처리
4. 모델은 독립적으로 작동할 수 있으며, 재사용 가능한 비즈니스 로직을 포함
5. 독립적으로 작동하며, 뷰와 컨트롤러와 직접적으로 통신하지 않는다.

모델은 애플리케이션의 데이터와 비즈니스 로직을 담당한다.

이는 데이터베이스의 테이블, 클래스 또는 기타 데이터 구조를 표현할 수 있으며 모델은 뷰나 컨트롤러에 직접적으로 정보를 전달하지 않고, 대신 상태 변화를 관찰하고 있는 객체들에게 상태 변경을 알린다.

이렇게 함으로써 모델은 사용자 인터페이스나 사용자 입력에 독립적으로 작동할 수 있게 된다.

라고 구글링을 좀 해보면 Model 에 관한 정보를 얻을 수 있다.

그렇다면 비즈니스 로직을 담당 한다는데 비즈니스 로직이 도대체 뭔지 감이 잘 안잡힌다.

👌 모델(Modle)에 적용되는 비지니스 로직

• 데이터 처리 : 모델은 데이터베이스와의 상호작용을 담당.
  데이터의 생성(Create), 조회(Read), 수정(Update), 삭제(Delete) 등의 CRUD 연산을 포함하며 SQL 쿼리 또는 ORM 도구를 통해 수행될 수 있다.

• 데이터 유효성 검사 : 모델은 데이터의 유효성을 검사하는 로직을 포함할 수 있습니다. 예를 들어, 사용자가 입력한 이메일 주소나 비밀번호의 형식이 올바른지, 입금 금액이 음수가 아닌지 등을 검사하는 로직이 이에 해당합니다.

• 서비스 로직 : 애플리케이션 내에서 필요한 모든 계산 로직도 모델에 포함.
  예를 들어, 쇼핑 애플리케이션에서 상품의 총 가격을 계산하거나, 금융 애플리케이션에서 이자를 계산하는 로직 등이 이에 해당한다.

📌 뷰(View)

단순하게 일반 사용자에게 보여지는 화면을 생각 하면 이해가 쉬울 것 같다.

이미지 출처 : 맛있는 외식의 시작 미리

• 사용자 인터페이스(UI)를 담당

• 모델에서 제공하는 데이터를 표시하고, 사용자의 입력을 받을 수 있는 화면을 제공

• 주로 HTML, XML, JSON 등의 형식으로 데이터를 표현

• 여러 개의 뷰가 동일한 모델을 사용할 수 있음

• 사용자 인터페이스의 외관과 레이아웃을 담당

📌 컨트롤러(Controller)

1. 클라이언트의 요청을 수신하고 처리하는 역할

2. 모델과 뷰 사이의 흐름을 조정하고, 비즈니스 로직을 수행하는 서비스와의 상호작용을 관리

3. 클라이언트의 요청을 분석하고, 해당 요청에 대한 모델 호출과 뷰 선택을 수행

4. 컨트롤러는 클라이언트와 상호작용하며, 모델과 뷰를 조정하여 애플리케이션의 동작을 제어

Spring Boot 프로젝트를 진행할때 @RestController 어노테이션이 적용된 Class 파일이 해당한다.

@Api(tags = "컨트롤러 Example")
@RestController or @Controller
@RequestMapping("/mvc/pattern")
public class MvcController {
	
    ... 생략
}

📈 MVC 패턴의 장점

• 분리된 역할 : 각 구성 요소의 역할이 명확하게 분리되어 있어, 코드의 가독성과 유지 관리가 용이.

• 유지보수 용이 : 구성 요소간의 낮은 결합도로 인해, 코드의 재사용성이 높아지며, 개별 구성 요소를 독립적으로 개발, 수정 및 테스트할 수 있다.

• 병렬 개발 : 동일한 모델을 여러 뷰에서 사용할 수 있으므로, 애플리케이션의 유연성이 향상 된다.

📉 MVC 패턴의 단점

• 복잡성 증가: 세 가지 컴포넌트를 관리해야 하므로, 초기 설계 단계에서 복잡성이 증가한다. 특히, 컨트롤러와 뷰 사이의 동기화를 관리해야 하는 어려움이 있을 수 있다.

• 코드 네비게이션 어려움: 코드를 네비게이션하는데 어려움이 있을 수 있다. 각 부분이 분리되어 있으므로, 하나의 기능을 이해하기 위해 여러 파일을 참조해야 한다.

🚀 종합

MVC 패턴은 각 구성요소가 각자의 역할에 집중할 수 있도록 해주므로, 코드의 가독성과 재사용성을 높이고 유지보수를 용이하게 한다.

하지만 이 패턴이 모든 상황에 적합한 것은 아니며, 특히 대규모 시스템에서는 MVC 패턴이 복잡성을 증가시키기도 한다.

따라서 프로젝트의 특성에 따라 적절한 디자인 패턴을 선택하는 것이 중요하다고 판단 된다.

📗 정리

"미리" 프로젝트를 진행 할 때 헥사고날 아키텍처, Domain Driven Design을 바탕으로 프로젝트에 맞게 변형하여 패턴을 시도 및 적용 했었다.

적용했던 디자인 패턴이 MVC 패턴과 기본 베이스가 크게 다르지 않아서 이전까지 구축했던 프로젝트 전체를 뒤엎지는 않았었다.

사용하던 MVC 패턴과의 어떤 차이점이 있는지 짚고 비교한 후 진행 하지 않았기 때문에 그냥 무작정 적용 했었다.

막상 적용하고 나니 계층마다 in, out Dto를 매번 생성해서 전달 해줘야 했기 때문에 작업량은 오히려 더 많아졌다.
물론 계층이 독립적으로 작동하니 예외 발생 시에 다른 계층을 확인 할 필요 없이 유지보수가 가능했던 것 같다.

추후 게시글에서 당시 적용했던 패턴에 대해서 일기 형태로 작성 해보기 위해 MVC 패턴에 대해서 한번 알아보고자 했다.

참고

https://2minmin2.tistory.com/65
https://mundol-colynn.tistory.com/147