MVC(Model-View-Controller) pattern

📒 MVC

MVC는 Model View Controller의 약자로 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴이다.

소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있다.

🔍 Model

어플리케이션이 '무엇'을 할 것인지 정의하고 데이터와 비즈니스 로직을 관리한다.

처리되는 알고리즘, DB와 상호작용(CRUD Create Read Update Delete), 데이터 등

🔍 View

화면에 '무엇'인가를 보여주기 위한 역할을 한다.

컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여준다.

최종 사용자에게 '무엇'을 화면(UI)으로 보여줌

🔍 Controller

모델이 '어떻게' 처리할 지를 알려주는 역할을 하고, 모바일에서는 화면의 로직처리 부분이다.

화면에서 사용자의 요청을 받아서 처리되는 부분을 구현하게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 된다.

Controller는 Model과 View가 각각 무엇을 해야 할 지를 알고 있고, 통제한다.

비즈니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기할 수 없게 한다.

MVC 예시

간단한 쇼핑 리스트 앱이 있다고 생각해보자. 이번 주에 사야할 각 항목의 이름, 갯수, 가격의 목록이 필요하다.

출처 : MDN

Model은 데이터의 상태가 변경되면 모델을 일반적으로 뷰에게 알리며(따라서 필요한대로 화면을 변경할 수 있다) 업데이트 된 뷰를 제거하기 위해 다른 로직이 필요한 경우 가끔 컨트롤러에게 알리기도 한다.

모델은 리스트 항목이 포함해야 하는 데이터 < 품목, 가격, 등 > 이미 존재하는 리스트 항목이 무엇인지를 지정한다.

View는 앱의 데이터를 보여주는 방식이며 항목이 사용자에게 보여지는 방식을 정의하며, 표시할 데이터를 모델로부터 받는다.

Controller는 앱의 사용자로부터의 입력에 대한 응답으로 모델 또는 뷰를 업데이트 하는 로직을 포함한다.

항목을 추가하거나 제거할 수 있게 해주는 입력 폼과 버튼을 갖는다. 이런 액션들은 모델이 업데이트 되는 것이므로 입력이 컨트롤러에게 전송되고, 모델을 적당하게 처리한 다음 업데이트된 데이터를 뷰로 전송한다.

항목을 알파벳 순서로 정렬한다던지 가격순으로 정렬하는 경우에는 모델을 업데이트 할 필요 없이 바로 처리할 수 있다.

🔍 Web과 MVC

출처 : 생활코딩

위 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 된다.

사용자가 웹 사이트에 접속한다. (USES)
Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출한다. (MANIPULATES)
모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.
Controller는 Model이 리턴한 결과를 View에 반영한다. (UPDATES)
데이터가 반영된 View는 사용자에게 보여진다. (SEES)

🔍 MVC 패턴의 필요성 및 한계점

디자인 패턴을 알기 전에는 온갖 모듈들이 뒤죽박죽 섞여 지저분한 코드로 가득했다. 이런 코드는 개발자 본인이 유지보수 하기에도 복잡하고, 다른 개발자가 투입되면 분석하기가 어렵고 유지보수 하기도 힘들다.

MVC 패턴은 역할에 따라 확실하게 분리하여 유지보수를 용이하게 하고 프로그램의 확장성과 유연성을 높이기 위한 기법이다.

데이터가 추가되면 Model 부분만 수정하고, UI가 수정되면 View 부분만 수정한다.

물론 Controller도 두 부분을 관장하기 때문에 일부 수정이 필요하지만 기존처럼 메인 다이얼로그/폼에서의 무분별한 하드 코딩은 필요가 없다.

서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 만들면 유지보수, 애플리케이션의 확장성, 유연성이 증가하고 중복코딩이라는 문제점 또한 사라진다.

한계점

한 Model은 다수의 View들을 가질 수 있고 반대로 Controller를 통해서 한 View에 연결되는 Model도 여러 개가 될 수 있다.

이렇게 되면 결과적으로 View와 Model이 서로 의존성을 띄게 된다.

물론 설계를 잘 한다면 Model간의 의존성 뿐만아니라 View와 Model 사이에 생기는 의존성도 줄일 수 있지만 프로그램 특성상 필연적으로 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있다.

이렇게 MVC 규모 자체가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 의존성을 일일이 해결해야해서 메소드 분석이나 테스트도 어렵게 된다. 이런 형태의 MVC를 Massive ViewController라고 부르는데, 이는 MVC의 한계를 표현한 용어이기도 한다.

출처