ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • MVC,MVP,MVVM 패턴의 이해
    Programming/Design Pattern 2022. 2. 10. 15:03

    소프트웨어 디자인 패턴이란, software engineering의 software design에서의 특정한 부분에서 반복적으로 발생하는 문제에 대하여 재사용이 가능하게끔 하는 해결책이다.

     

    우선 들어가기에 앞서서 MVC 패턴은 자바와 스프링 프레임 워크를 처음 접하던 2016년 부터 써왔으며, 첫직장에서 엘라스틱 서치와 더불어 자바, 스프링,JSP 등을 이용하여 특허검색 시스템을 개발하면서 실무에서 사용해봤기 때문에 무척이나 익숙하였고, 이후 리액트와 노드 등을 이용하여 서비스를 개발할 때에도 은연중에 모델과 뷰 그리고 컨트롤러를 분리하는 디자인 패턴을 기본적으로 적용하여 개발하였었다. 하지만 자바+스프링 만큼 뚜렷하게 구분이 되었던 것은 아니고 뷰는 리액트, 모델과 컨트롤러는 노드를 이용하여 사용자의 요구를 처리하고 데이터베이스와 통신하여 요구된 데이터를 반환하는 로직으로 구성하여 개발하였다.

     

    잡담은 이쯤하고, 우선 디자인 패턴 중에 대표적이고 흔하게 쓰이는 MVC모델에 관하여 살펴보자.

    이 디자인 패턴은 Model+View+Controller의 첫글자를 딴 용어로써 이름에서 알 수 있듯이 전체적인 시스템의 구조를 3가지로 나누어서 로직을 구성하는 것이라고 볼 수 있다.

    먼저 Model이라고 하는 부분은 시스템 내부의 데이터 혹은 그 데이터를 처리하는 부분이며, View는 유저에게 보여지는 시각적인 부분, UI/UX에 해당한다.

    마지막으로 Contorller는 뷰에서 유저의 조작이 발생하면 그 발생한 이벤트를 드리븐 하는 로직이라고 볼 수 있다. 이때 컨트롤러와 뷰는 1:n 구조인데, 컨트롤러가 여러개의 뷰를 선택할 수 있는 구조이다.

    그렇다고 컨트롤러가 직접 업데이트 하는 것은 아니니 유의하자. 이러한 MVC 패턴은 흔하게, 보편적으로 사용 된다는 점이 장점이라고 볼 수 있지만 반대로 그것이 단점이 되는데 바로 뷰와 모델 사이의 의존성이 강하다는 것이다.

    모델이 데이터를 반환하지 않으면 뷰는 업데이트 될 수 없기 때문에 치명적인 상황이 발생 할 수 있으며, 프로젝트의 규모가 커지고 소스 코드의 양이 많아 질 수록 모델과 뷰의 관계와 로직이 복잡해지고 유지보수의 난이도가 상승한다는 점이 있다.

     

    다음으로는 MVP모델이다.

    MVP패턴은 Model+View+Presenter의 앞글자를 딴 용어인데, 컨트롤러 대신 Presenter로 바뀐 구조이다.

    이는 뷰에서 유저의 액션이 발생하고 넘어온 데이터와 요청을 모델로 dispatch해주고 모델은 필요한 데이터를 가공하여 다시 Presenter로 반환해주면 이를 뷰로 보내주는 구조이다.

    모델과 뷰 사이에서 중계자 역할을 한다고 볼 수 있다. MVP 패턴의 특징은 View와 Presenter는 1:1 관계라는 것이고, 덕분에 VIew와 Model 사이의 의존성이 해결되었다는 점이다.

    하지만 단점으로 Presenter와의 의존성이 프로그램이 복잡해질수록 더욱 심화된다는 점이 있다.

     

    마지막으로 MVVM모델이다.

    처음에 봤을 때 VM이 무엇일까 했는데, 다름이 아니라 ViewModel이라는 것 이였다. 뷰와 모델을 합친 것인데, Model View ViewModel의 앞글자를 따서 지은 이름인 것이다.

    새로이 추가된 VM은 앞선 두 모델의 Controller와 Presenter를 대체하는 것인데 이는 뷰를 표현하기 위한 모델, 즉 뷰만을 위한 데이터를 처리하는 모델인 것이다.

    하여 MVP와는 달리 MVC와 같이 뷰와 뷰모델의 관계가 1:n 이지만 데이터의 흐름이 반대라는 점이 차이점이다.

    사용자의 액션이 다양한 뷰로 입력이 되면 Command Pattern을 통하여 전달하는데 이를 처리하는 ViewModel로 Data Flow가 형성되고 이는 곧 Model로 필요한 데이터에 대한 요청이 전해져 반환받은 필요한 데이터를 가공하고 처리하여 저장하면 뷰에서 Data Binding을 통하여 화면을 뿌려준다.

    해당 모델에서는 커맨드 패턴과 데이터 바인딩 두가지를 이용하여 뷰와 뷰모델 간의 의존성을 해결하였기 때문에 Modularization이 가능하지만 뷰모델의 개발이 난이도가 높다는 단점이 있다.

    댓글

Designed by Kort.