MVC(Model-View-Controller) 패턴
- 어플리케이션을 Model-View-Controller 세 가지 역할로 구분한 소프트웨어 디자인 패턴
- 비지니스 로직과 화면을 구분한다.
- Back단과 Front단을 구분한다. → 유지보수를 독립적으로 수행 가능하다.
- Model과 View가 다른 컴포넌트들에 종속되지 않는다. → 애플리케이션 확장성, 유연성, 재사용성
Model : Data, 정보의 가공
- 어플리케이션의 정보, 데이터
- 데이터베이스로부터 가져온 정보, 처음에 정의하는 상수, 초기화 값, 변수 등
- 사용자가 편집하길 원하는 모든 데이터를 갖고 있어야 한다.
- 화면 안에 네모 박스 속 글자가 표현된다고 한다면, 모델은 네모 박스의 위치정보, 크기정보, 글자 내용 정보 등등을 가지고 있어야 한다.
- View나 Controller에 대해서 어떤 정보도 알면 안된다.
- 사용자가 데이터 변경을 요청했을 때, 모델이 직접 UI를 수정하는 로직을 갖고 있으면 안된다.
- 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 한다.
- 모델의 속성 중 하나가 변경되었다면, 이벤트를 발생시켜 사용자에게 전달해야 한다. 이벤트 반응 로직을 구현해야 한다.
View : User Interface, 사용자에게 보여지는 부분
- 사용자가 보는 화면
- 사용자와 상호작용 하면서 Controller로부터 받은 Model의 결과값을 화면으로 출력한다.
- Model이 가지고 있는 정보를 따로 저장하면 안된다.
- View에 네모를 그리라는 요청을 받았을 때, 요청을 내리기까지의 과정이나 사용했던 정보들을 View 내부에 저장하면 안된다.
- Model이나 Controller의 구성요소들을 몰라야 한다.
- 다른 요소들을 참조하면 안된다. View는 데이터를 받고 표시해주는 역할만 한다.
- 변경이 일어나면 변경 통지에 대한 처리 방법을 구현한다.
- 변경이 일어났을 때, 사용자에게 알리는 이벤트를 동작하는 로직을 구현해야 한다.
Controller : Bridge, 모델(Model)과 뷰(View) 사이를 이어주는 역할
- 서로의 존재를 모르는 Model과 View 사이를 연결하는 중재자 역할
- 사용자가 접근한 URl에 따라 사용자의 요청사항 파악 → 요청에 맞는 데이터를 Model에게 의뢰 → Model이 가공한 데이터를 받아서 View에 보내준다.
- Model이나 View에 대해서 알고 있어야 한다.
- Model이나 View의 변경을 모니터링 해야한다.
- Model이나 View의 변경 이벤트를 받으면 각각의 구성요소에 알려야 한다.
Spring MVC
- Spring Framework의 하위 모듈로, Model, View, Controller를 명확하게 분리한다.
- 매우 유연하고 확장성이 좋다.
- View는 View만 계속 개발하면 되고, Model은 Model만 계속 개발하면 된다.
Spring MVC 동작 흐름
- 사용자로부터 요청이 들어온다.
- Dispatcher Servlet이 요청을 받아서 Handler Mapping에게 요청을 처리할 컨트롤러를 찾게 한다.
- 컨트롤러를 찾으면, 그 컨트롤러를 실행시킬 수 있는 Adapter를 탐색한다.
- 탐색한 Adapter를 가지고 Controller는 데이터를 보내게 되는데, Model에게 데이터를 보내 가공도 하고, DB랑 통신도 해서, 그 결과 값을 응답으로 전해준다.
- Controller에서 view name을 보내며, 전달 받은 응답 값을 화면에 그려달라고 요청한다.
- Dispatcher Servlet은 Controller에서 받은 view name으로 View Resolver가 View를 찾게 만든다.
- View에서 응답값을 화면에 그려 사용자에게 보낸다.
[참고자료]
https://velog.io/@oyunseong/MVC-패턴이란
