MVC, MVP란? 그림과 함께 개념 및 차이점 이해하기

MVC패턴은 실무에서도 자주 만날 수 있는, 그만큼 가장 보편적이고 간단한 디자인 패턴 중 하나입니다.  MVC 패턴으로 코드 작성을 하고 있지만 Model - View - Control 각각의 간단한 기능정도만 이해하고 있던 와중에 다른 디자인 패턴들은 무엇이 있는지 궁금해서 공부하며 정리해보았습니다. 마구잡이로 코딩을 하는 것보다 적절한 디자인 패턴을 적용하면 한눈에 보기 훨씬 편한 코드, 구조가 되고 장기적으로 유지보수에 좋기때문에 프로젝트에 따라 디자인 패턴을 정하는 것이 중요합니다. 

 

먼저 가장 기본이 되는 MVC 부터 자세히 알아봅시다.

 

처음에는 디자인 패턴이 무엇이지? 감이 안잡혔습니다. 지금에서야 조금씩 드는 생각은 코드가 점차 많아지고 장기적으로 유지 보수, 확장하게되면 중구난방으로 될 가능성이 높은데, 기능별로 코드를 처음부터 나누어 작성하게되면 관리하기도, 확장하기도 유지보수하기도 편해집니다. 코드를 어떤기능으로, 어떤 구조로 나눌지 약속한 것이  소프트웨어 디자인 패턴입니다.

 

MVC : Model - View - Controller 

MVC 패턴이란 하나의 application의 기능을 3 가지 메인 components로 나누는 소프트웨어 디자인 패턴 중 하나입니다. 

 

MVC Pattern
Model	data & buisiness logic
View	유저 인터페이스 & 유저에게 보여지는 데이터
Controller	유저로부터의 인풋값을 핸들링하고 model과 view를 업데이트 / 흐름을 담당

 

이름 그대로 Model 은 DB 모델과 관련된 일을 처리하고 View는 "보는 것" 즉, 유저 입장에서 보는 곳 = 프론트를 말하고 컨트롤러는 흐름을 "컨트롤" 합니다. 이렇게 세 부분으로 나누어 코드를 작성하게되면 한쪽을 수정하더라도 다른 쪽에 영향이 가지 않습니다. 예를 들어, ui 디자인을 바꿀 필요가 있는 경우 view 만 고치면 됩니다. 

 

예를 들어, 간단한 웹에서 유저가 본인의 프로필 정보를 보고 또 수정할 수 있는 페이지가 있다고 해봅시다. 그럼 위 3개의 파트들은 맡은 바가 아래와 같습니다. 

model	유저의 프로필 정보 (inside the db), db를 업데이팅하는 로직을 담당
view	유저에게 보여주는 html, css 담당
controller	유저로부터 받는 input 핸들링 담당 (전달해주는 애)

 

특징 

1. 최초 Input은 Controller로 향한다. 

2. View와 Controller는 다대다 관계를 가진다.

3. View는 Controller 에 대한 정보가 없다.

4. View는 Model이 데이터를 전달할 것을 알고 있다.

 

MVC 패턴의 동작 순서 

1.  view를 바라보고 있는 유저가 화면에서 어떤 동작을 취하면 (업데이트 etc) view는 "request" (요청)을 controller 로 보냅니다. 

2. 요청을 받은 controller는 "request" 요청을 받아 요청대로 model 을 업데이트합니다.

3. model은 업데이트를 수행하며 view에게 알려줍니다. "나 업데이트 처리했다~" 

4. view는 유저가 바라보는 본인(user interface)을 업데이트합니다. 

 

 유저가 어떠한 액션을 취할 때마다 (when interacting with the application) 위의 1~4번이 반복됩니다. 

 

 

MVC 패턴의 장점

1. 기능 분리로 인한 이점

- 각각의 components 들은 독립적으로 개발, 테스트, 유지, 보수할 수 있습니다.

 

2. 재사용성 향상

- 분리된 components 는 재사용이 용이하고 새로운 기능들을 추가하기에도 편리합니다. 

 

3. 깔끔한 구조 

- MVC의 organized 구조 덕분에 코드를 장기적으로 유지하고 확장하기 용이합니다.

 

4. 높은 유연성

- 화면(view) 또는 db 관련 (model) 코드를 수정해야할 때 이미 분리되어 있기 때문에 서로의 component를 침범하지 않습니다. 

 

5. 테스트 용이 

- 역시나 분리된 구조는 테스트를 각각 독립적으로 하기에 용이합니다. 

 

 

MVP 패턴의 단점

1. Model 과 View 사이의 의존성

- application의 장기적 확장, 유지 보수에 어렵습니다.

 

 

 

---

 

 

 

MVC의 단점인 Model과 View의 의존성을 완화하고자 나온 패턴이 바로 MVP입니다. 

 

MVP : Model - View - Presenter

MVP 패턴 역시 MVC와 동일하게 하나의 application의 기능을 3 가지 메인 components로 나누는 소프트웨어 디자인 패턴 중 하나입니다. MVC와 한 가지 달라진 점은 징검다리 역할을 한 Controller 가 Presenter로 바뀐 것입니다.

 

MVC Pattern
Model	data & buisiness logic
View	유저 인터페이스 & 유저에게 보여지는 데이터
Presenter	(MVC 의 기존 기능이었던) -->  유저로부터의 인풋값을 핸들링하고 model과 view를 업데이트 / 흐름을 담당 (새로운 기능 추가됨) --> 모델로부터 데이터를 받아 View (화면)을 업데이트

 

Model과 View는 위의 MVC와 비슷하고 눈 여겨 볼 것은 Presenter 입니다. 기존 controller의 역할을 하지만 하나가 더 추가되었습니다. 기존에는 View 유저 ---> 에서 받은 input을 핸들링만 담당하다가 이제는 Model ---> View 의 핸들링까지 담당하게 됩니다. MVC 패턴의 그림과 MVP 패턴의 그림을 잘 비교해보면 controller 로부터 Out 나가는 방향의 화살표는 1개인데 MVP의 경우, presenter는 2개가 보입니다. 그리고 Model과 View간의 소통이 없습니다. 이는 Model과 View의 모든 흐름을 Presenter가 총괄해주며 아래에 나올 장점을 만들어주게 됩니다. 

 

 

특징

1. 최초 input은 View로 향한다.

2. View와 Presenter는 1:1 관계이다.

3. View는 본인의 Presenter 참조를 가지고 Presenter도 해당 View를 알고 있다.

4. View는 Model을 알지 못한다. Presenter가 Model을 update한다. 

 

MVP 패턴의 동작 순서 

1.  view를 바라보고 있는 유저가 화면에서 어떤 동작을 취하면 (업데이트 etc) view는 presenter에 요청을 보냅니다. 

2. presenter는 받은 요청대로 model 을 업데이트합니다. 

3. model은 presenter로 업데이트된 데이터를 보냅니다. (by GET method)

4. presenter는 받은 데이터를 view 로 업데이트 합니다. (Presenter와 View는 1:1 관계)

5. view 는 유저가 바라보고 있는 본인 (user interface) 를 업데이트합니다. 

 

유저가 어떤 액션을 취할 때마다 위의 과정이 반복됩니다. MVC가 Controller 중점의 느낌이라면 MVP는 View가 중점이 된 느낌입니다. 

 

 

MVP 패턴의 장점

1. MVC 패턴의 분리된 components로 인한 장점과 동일합니다.

 

2. Model과 View의 의존성이 없습니다.

- MVC의 view - model 과 달리 의존성이 없음

 

3. unit test 하기에 편리합니다.

- view와의 상호작용이 인터페이스를 통한 것이기 때문

 

 

MVP 패턴의 단점

1. 복잡한 Presenter

- 모든 흐름을 핸들링을 하는 presenter가 꽤나 복잡해질 가능성

- view와 presenter가 1:1 관계이기 때문에 서로 간 의존성이 높음

 

 

 

---

 

 

 

일반적으로 큰 스케일의 application의 경우 더 복잡한 유저 인터페이스가 필요한 경우 MVP를, 비교적 작은 application과 간단한 유저 인터페이스의 경우 MVC가 적합하다고 합니다. 하지만 팀의 취향 또는 프로젝트별 요구사항에 따라 가장 적절한 패턴을 선택하시면 될 것 같습니다.