[Design Pattern] MVC pattern (Model View Controller)

해당 게시글은 개인적인 공부를 정리한 것으로 부족한 부분이 있을 수 있습니다.

---

MVC design pattern

MVC 디자인은 가장 널리 알려진 소프트웨어 디자인 패턴 중 하나로서 애플리케이션을 Model - View - Controller 세 가지의 파트로 나누어 다룹니다. MVC 패턴의 핵심은 비즈니스 로직과 보여지는 레이어(UI)를 분리하여 시각적 요소와 그 이면에서 실행되는 로직을 서로의 영향 없이 쉽게 수정이 가능하게끔 하는 것입니다. 

Model (모델)

모델은 이 어플리케이션이 무슨 일을 하는지를 정의합니다. 애플리케이션의 데이터 베이스, 알고리즘, 로직 등이 모델이 됩니다. 모델 안의 데이터가 변경될 경우 직접 컨트롤러에게 값을 전달하는 것이 아닌 브로드캐스팅 (Noticication or KVO: Key Value Observing) 방식을 사용하여 변화를 알립니다.

View (뷰)

뷰는 유저가 모델의 데이터를 볼 수 있게끔 합니다. 컨트롤러에 종속적이며 텍스트, 버튼 , 차트 등 사용자 UI를 나타냅니다. 뷰는 자신이 출력하고 있는 데이터를 소유 할 수 없고 컨트롤러에게 항상 요청해야 합니다. 뷰에서 사용자 입력이나 변화가 생기면 Action을 컨트롤러에게 Target에 맞추어 보냅니다. 또한 뷰는 컨트롤러와 동기화 하기위해서 미리 정의된 delegate 메소드를 통해 컨트롤러와 입력에 대한 다음 동작에 대해 소통합니다. 뷰의 Datasource 메소드는 컨트롤러에게 데이터를 요청해서 뷰에서 보여질 데이터를 받습니다.

Controller (컨트롤러)

뷰와 모델을 관리하며 뷰로부터 들어온 사용자의 요청을 받아 모델이 어떻게 처리 할지를 알려주는 역할이며, 뷰를 위해 모델의 데이터를 해석하고 어떻게 모델이 UI로 표현될지를 정의합니다. 사용자의 요청 내용을 분석해서 모델과 뷰에 업데이트합니다. 모델의 변화를 수신하여 처리합니다.

M - V - C 간의 소통

• 일반적인 경우 뷰와 모델은 무조건 컨트롤러를 거쳐서 소통합니다.
  
  
• 컨트롤러는 모델과 뷰를 통제합니다.
  
  
• 뷰의 객체들은 컨트롤러에 대해 알지 못하고 메소드를 호출하여 컨트롤러와 소통합니다. 

MVC design pattern 의 장점

애플리케이션의 코드를 세 가지 기능에 맞추어 분리하고 개발하기 때문에 동시 개발이 가능하며 유지 보수, 확장성, 코드의 재사용 등이 쉬워집니다. 

MVC design pattern의 한계

보통 이러한 여러 MVC가 모여서 하나의 애플리케이션이 되는데 만약 화면 구성과 데이터 구성이 복잡해질 경우 경우 하나의 컨트롤러에 다수의 모델과 뷰가 연결되는 상황이 생깁니다. 이럴 경우 코드의 재사용과 수정이 상당히 어려워지게 됩니다.

---

마무리 & Reference

다음 포스팅에서 Delgate , DataSource, KVO, noticification 방식을 공부하며 더 자세히 다뤄보겠습니다.

• www.educative.io/blog/mvc-tutorial

• www.youtube.com/watch?v=zazVxjuEXok