MVC란 Model-View-Controller의 약자로 애플리케이션을 세 가지 역할로 구분한 디자인 패턴중 하나이다.
소프트웨어 디자인 패턴은 소프트웨어 공학의 소프트웨어 설계에서 특정 상황에 공통적으로 발생하는 문제에 대한 해결책이다.
사용자가 입력을 담당하는 View를 통해 요청을 보내면 해당 요청을 Controller가 받고, Controller는 Model을 통해 데이터를 가져오고, 해당 데이터를 바탕으로 출력을 담당하는 View를 제어해서 사용자에게 전달한다.
이러한 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 됩니다.
동작방식
- 사용자가 웹사이트에 접속
- Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출
- Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
- Controller는 Model이 리턴한 결과를 View에 반영
- 데이터가 반영된 View는 사용자에게 보여짐
MODEL
데이터와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할
컨트롤러가 모델을 호출을 하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 연관된 비즈니스 로직을 처리하는 역할 수행
데이터 추출, 저장, 삭제, 업데이트 등의 역할을 수행
1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다
2. 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록, 뷰를 참조하는 내부 속성값을 가지면 안 된다. -> 존재 자체를 몰라야 된다
3. 변경에 대한 수신 처리 방법, 전달 처리 방법을 구현해야 된다.
컨트롤러가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법, 모델의 정보가 변경이 된다면, 이벤트를 발생시켜 뷰에게 반영할 전달 처리 방법을 구현해야 한다
또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.
View
input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타낸다. 사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 합니다.
1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안된다. 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 한다.
2. 모델이나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안된다. 그냥 뷰는 데이터를 받으면 화면에 표시해주는 역할만 가진다고 보면 된다. -> 존재 자체를 몰라야 된다
3. 변경에 대한 수신 처리 방법, 전달 처리 방법을 구현해야 된다.
유저가 변경에대한 액션을 일으키면 이것을 컨트롤러에게 전달 할 전달처리 방법과 컨트롤러어에 의해 디스플레이변경 이벤트를 수신 할 수 있는 처리 방법,
Controller
화면과 Model과 View를 연결시켜주는 역할 , Model이 데이터를 어떻게 처리할지 알려주는 역할
사용자로부터 View에 요청이 있으면 Controller는 해당 업무를 수행하는 Model을 호출하고 Model이 업무를 모두 수행하면 다시 결과를 View에 전달하는 역할을 합니다
1. 모델이나 뷰에 대해서 알고 있어야 한다.
모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 한다.
2. 모델이나 뷰의 변경을 모니터링 해야 한다.
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 한다.
또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 된다.
장점
- 각 구성요소들을 독립시켜 협업을 할 때 맡은 부분의 개발에만 집중할 수 있어 개발의 효율성을 높여준다.
- 개발 후에도 유지보수성과 확장성이 보장된다.
단점
- 한개의 모델이 여러 뷰를 조작하고, 한개의 뷰가 여러 개의 모델을 조작한다면 데이터 흐름을 알기 힘들어진다.
- 프로젝트가 커질수록 버그를 찾기 어려워지고, 흐름을 추적하는데 많은 시간 소요
