MVC Pattern

ⅰ) Model

!!→ 데이터(data)가공을 책입지는 컴포넌트(component)
- 모델은 어플리케이션의 정보, 데이터를 나타냄
- 데이터베이스, 초기화 된 상수나 값, 변수 등을 뜻함
- 비지니스 로직을 처리한 후 모델의 변경 사항을 컨트롤러와 뷰에 전달함
- Model의 규칙
    - 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 함
    - 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 함
    - 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만함

ⅱ) View

!! → 사용자에게 보여지는 부분, 즉 유저 인터페이스(User interface)를 의미함
- MVC 패턴은 여러 개의 뷰가 존재할 수 있으며, 모델에게 질의하여 데이터를 전달받음
- 뷰는 받은 데이터를 화면에 표시해주는 역할을 가지고 있음
- 모델에게 전달받은 데이터를 별도로 저장하지 않아야 함
- 사용자가 화면에 표시된 내용을 변경하게 되면 모델에게 준달하여 모델을 변경해야 함
- View의 규칙
     - 모델이 가지고 있는 정보를 따로 저장해서는 안됨
     - 모델이나 컨트롤러와 같이 다른 구성 요소들을 몰라야 함

ⅲ) Controller

!! → 모델과 뷰 사이를 이어주는 브릿지(bridge)역할을 의미함
- 모델이나 뷰는 서로의 존재를 모르고 있고 변경 사항을 외부로 알리고 수신하는 방법만 있음 → 컨트롤러는 이를 중재하기 위한 컴포넌트
- 모델과 뷰에 대해 알고 있으며 모델이나 뷰로부터 변경 내춍을 통지 받으면 이를 각 구성 요소에게 통지함
- 사용자가 어플리케이션을 조작하여 발생하는 변경 이벤트들을 처리하는 역할을 수행함
- Controller의 규칙
    - 모델이나 뷰에 대해서 알고 있어야 함
    - 모델이나 뷰의 변경을 모니터링해야 함

ⅳ) MVC pattern을 사용하는 이유

!! → 유지보수의 편리성
- 최초 설계를 꼼꼼하게 진행한 시스템이라도 유지 보수가 발생하기 시작하면 각 기능간의 결합도(coupling)가 높아짐
- 이는 최초 설계 이념을 정했던 사람들의 부재 혹은 비즈니스 요건 변경으로 인해 필연적으로 발생함 → 결합도가 높아진 시스템은 유지보수 작업 시 다른 비즈니스 로직에 영향을 미치게 되므로 사소한 코드의 변경이 의도치 않은 버그를 유발할 수 있음
- 디자인 패턴이란 개발하는 과정에서 마주치는 문제들을 해결하기 위해 UI 시스템을 위한 책임을 기준으로 3개의 핵심 컴포넌트 모델, 뷰, 컨트롤러라는 책임을 나누고 각 컴포넌트가 자신의 수행 결과를 다른 컴포넌트에게 전달하는 프로그래밍 방식으로 결합도를 낮춤
- 시스템 유지보수 시에도 특정 컴포넌트만 수정하면 되기 때문에 보다 쉬운 시스템 변경이 가능함
- 화면의 변경은 뷰를 수정하여 반영함
- 데이터나 비즈니스 요건의 변경은 모델을 수정하여 반영함
- 뷰와 모델 변경에 따른 컨트롤러를 수정해아함

📌

MVC 패턴에도 한계가 존재함 → 복잡한 대규모 프로그램의 경우 다수의 뷰와 모델이 컨트롤러를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생함 복잡한 화면을 구성하는 경우에도 동일한 현상이 발생하는데 이를 “Massive-View-Controller”라고 함 ⇒ 이러한 문제점을 보완하기 위해 다양한 패턴이 파생됨

• MVP 패턴
• MVVM 패턴
• Flux
• Redux
• RxMVVM