4. MVC 패턴

MVC

: Model, View, Controller의 각 머릿글자를 따온 표현으로 프로젝트나 앱을 구성할 때 구성 요소를 세가지 역할로 구분한 것

- 비즈니스 로직 자체를 컨트롤러에서 핸들링 하게 되면 컨트롤러에 너무 많은 책임이 부과됨

-> 일반적으로 비즈니스 로직은 Service 계층을 두어 따로 처리

- JSP만으로 구현한 웹앱에서는 비즈니스 로직의 노출, 가독성 저하와 같은 문제점이 발생

 

Model, View, Controller의 관계

1. 사용자의 request를 controller가 받음
2. controller는 service에서 비즈니스 로직을 처리한 후 결과를 model에 담음
3. model에 저장된 결과를 바탕으로 시각적 요소 출력을 담당하는 view를 제어하여 사용자에게 전달

- web)

1. User : 사용자가 웹 사이트에 접속
2. Manipulates : Controller는 사용자가 요청한 웹 페이지를 보여주기 위해 Model을 호출
3. Updates : Model은 비즈니스 로직을 통해 DB 및 파일과 같은 데이터를 제어한 후 결과를 반환 -> Controller는 Model에게 반환받은 결과를 View에 반영
4. Sees : 데이터를 받아온 View가 사용자에게 웹 페이지를 출력하여 보여줌

 

Model

: 소프트웨어나 애플리케이션에서 정보 및 데이터 부분을 의미

- Controller에게 받은 데이터를 조작하는 역할을 수행

- 데이터와 관련된 부분을 담당하며 값과 기능을 가지는 객체

- 규칙 )

• 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 함
• View나 Controller에 대해서 어떤 정보도 알지 말아야 함
• 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 함

View

: 사용자 인터페이스 요소

- Controller에게 받은 Model의 데이터를 사용자에게 시각적으로 보여주기 위한 역할을 수행

- 사용자에게 보여지는 화면

- 규칙 )

• Model이 가지고 있는 정보를 따로 저장해서는 안됨
• Model이나 Controller를 알고 있을 필요가 없음
• 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 함

Controller

: Model과 View 사이에서 데이터 흐름을 제어

- 사용자가 접근한 URL에 따라 요청을 파악하고 URL에 적절한 Method를 호출하여 Service에서 비즈니스 로직을 처리

- 결과를 Model에 저장하여 View에게 전달하는 역할을 수행

- Model과 View의 역할을 분리하는 중요한 요소

- 규칙 )

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

장점과 한계점

- 장점 )

• 관심사 분리
• 컴포넌트의 명확한 역할 분리로 인해 서로간의 결합도를 낮출 수 있음
• 코드의 재사용성 및 확장성을 높일 수 있음
• 서비스를 유지보수하고 테스트하는 데 용이해짐
• 개발자 간의 커뮤니티케이션 효율성을 높임

- 한계점 )

• Model과 View의 의존성을 완전히 분리시킬 수 없음
• Controller의 비중이 높아져 부담이 커진다면 Massive-View-Controller 현상을 피할 수 없음

 

 

 

 

 

 

 

 

 

 

Reference

https://velog.io/@langoustine/%EC%97%AC%EA%B8%B0%EB%8F%84-MVC-%EC%A0%80%EA%B8%B0%EB%8F%84-MVC-MVC-%ED%8C%A8%ED%84%B4%EC%9D%B4-%EB%AD%90%EC%95%BC