yubin

I am an amazing person.

카테고리 (펼쳐보기)

디자인 패턴은 매번 사용하는 패턴만 잘 기억하고 그렇지 않은 것은 잊어버리는게 일상이라 다음에 잊어버렸을때 빠르게 기억을 되돌리기 위해서 정리를 했다.

사실 공부를 하면서 혼란스러운 부분도 많았고, 나름 여러 자료를 보며 정리를 했지만 틀린 부분이 있을 수도 있을 것 같다.

들어가며

MVC를 공부하기 위해 여러 자료를 조사했는데 뭔가 자료마다 말이 조금씩 달라서 혼란스러웠다.

어떤 자료는 컨트롤러를 통해서 뷰를 갱신해야한다고 하고, 어떤 곳에서는 모델이 뷰를 바로 갱신하고 아주 대혼란 잔치가 따로 없었다.

거의 두 시간 동안 똑똑한 백엔드 친구와 열심히 토론하면서 MVC의 시초가 된 논문부터 쭉 역사를 따라가본 결과 다음과 같은 결론에 도달했다.

MVC는 시대가 지나며 개발 환경에 따라 다양한 방식으로 발전해 왔으며, ‘정확히 이것만이 MVC다!’ 라고 정의할 수 없다는 것이다.

비단 MVC뿐만 아니라 여러 기술이 이런 식일것 같다는 생각이 들었고, 변하지 않는 기술의 핵심 의의(어떤 목적으로 고안되었는가)에 집중할 필요가 있어보인다.

디자인 패턴의 사용 이유

  • 관심사 분리를 통한 유지보수성 향상


MVC(Model, View, Controller) : 모델과 뷰를 분리하자!

내가 생각하는 MVC의 핵심은 모델과 뷰의 관심사 분리이며, 이부분에 집중하기로 했다.

구성 요소

  • Model : 앱의 데이터, 비즈니스 로직 등의 코드
  • View : 유저에게 보여지는 사용자 인터페이스 요소
  • Controller : 뷰와 모델의 중간 다리 역할

동작 흐름

이 부분은 여러 형태가 있을것이라고 생각하지만, 안드로이드 개발을 주로 하기떄문에 내가 익숙한 형태로 흐름을 구성해보았다.

  1. 유저의 이벤트가 컨트롤러로 들어온다.
  2. 컨트롤러가 뷰를 참조하여 관련된 데이터를 뷰에서 가져온다.
  3. 컨트롤러는 유저 이벤트에 따라 모델의 데이터를 갱신한다.
  4. 컨트롤러에서 모델의 데이터를 조회한다.
  5. 컨트롤러는 조회한 데이터를 활용하여 적절한 뷰를 선택하고 갱신한다.

장단점

장점

  • 재사용성, 확장성 향상

단점

  • 앱이 복잡해질수록 컨트롤러가 복잡해지고 비대해짐

MVP(Model, View, Presenter) : 모델과 뷰를 더 분리하자!

개인적인 추측으로 MVP가 고안된 이유는 아래와 같다고 생각한다.

  1. 컨트롤러가 너무 커지는 것을 막기 위해 프레젠터를 활용해 뷰에 대한 책임을 분리.

  2. MVC에서 view와 controller를 다른 구성요소로 분리하는 것에 어려움이 있음.

특히 두번째 이유같은 경우는 안드로이드 개발을 주로 하는 내 입장에서는 view(xml)과 controller(activity)가 거의 한쌍처럼 붙어다니는데 controller를 통해 model과 의존성을 줄인다는 것이 뭔가 시원하지 않은 느낌이 들었다.

그러다 보니 view에 MVC의 view와 controller의 개념을 함께 포함하는 MVP가 MVC를보다 좀더 현실적인 쪽으로 발전시키려는 시도가 아닐까 하는 생각도 든다.

하여간 뭐가 됐든 주요한 핵심적인 고안 배경은 뷰와 모델의 분리를 더 깔끔하게 하려는 시도라고 생각한다.

구성요소

  • Model: MVC와 같이 앱의 데이터나, 비즈니스 로직 등의 코드
  • View : MVC의 controller+view의 느낌이다. ( 안드로이드로 생각하면 activity,fragment와 같은 controller가 MVP에서는 view에 포함된다. )
  • Presenter : view와 1:1로 연결되어 뷰와 모델을 연결한다.

동작원리

  1. 뷰가 유저 이벤트를 받는다.
  2. 받은 뷰가 자신의 프레젠터를 통해 데이터를 요청한다.
  3. 프레젠터는 모델에 데이터를 요청한다.
  4. 모델은 프레젠터에게 데이터를 반환한다.
  5. 프레젠터는 자신의 뷰에게 해당 데이터를 전달하면 뷰는 해당 데이터를 사용해 스스로를 갱신한다.

MVC의 경우 컨트롤러가 갱신할 뷰를 지정하고 갱신하는 역할까지 담당하고 있었지만, MVP의 경우 이런 부분이 더 확실히 분리된것 같다.

장단점

장점

  • 컨트롤러의 역할이 줄어든다.
  • 뷰에 뷰의 현재 상태와 관련된 코드만 남길 수 있다.

단점

  • 뷰와 프레젠터 사이의 의존성이 커진다.
  • MVC와 비슷하게 앱 규모가 커지면 프레젠터가 비대해진다.

MVVM(Model, View, ViewModel) : 뷰의 의존성을 줄여보자!

구성요소

  • Model: 데이터 관리, 비즈니스 로직
  • View: 사용자 눈에 보이는 유저인터페이스 관리
  • ViewModel: 뷰와 모델 사이의 중재역할 및 뷰의 상태 저장

동작원리

  1. 뷰가 유저 이벤트를 받아 뷰모델 함수를 트리거한다.
  2. 뷰모델에서 모델에 데이터를 요청한다.
  3. 모델이 데이터를 뷰모델로 반환한다.
  4. 뷰모델은 해당 데이터를 토대로 내부 데이터를 갱신한다.
  5. 뷰는 뷰모델 데이터의 변화를 감지하여 갱신된다.

장단점

장점

  • 뷰의 의존성이 줄어든다.

단점

  • 설계가 복잡하여 작은 규모의 앱에서는 사용하기 번거롭다.
  • (안드로이드) databinding을 사용하면 디버깅이 어려워진다.

MVI(Model, View, Intent) : 상태관리를 쉽게 해보자!

인것 같은데 이부분은 아직 공부 예정이다. 대충 몇몇 구현을 봤는데 컴포즈랑 쓰기 좋다고 한다. 나도 MVVM을 주로 쓰면서 상태관리가 힘들다고 느낀 때가 종종 있었는데, 잘 공부해서 이부분을 보완할 수 있었으면 좋겠다.

마무리

나름 정리를 한다고 해봤는데 하루종일 보다보니 이게 맞나 싶은게 몇 가지 보이는 것 같다.

위에서도 언급했지만 그냥 내가 공부하고 사용해봤던 내용을 정리한거라서 틀린 부분이 있을 수 있다.

이부분은 나중에 틈틈히 새로 알게된 내용이 생기면 보충해서 수정할 생각이다.

참고

  • https://folk.universitetetioslo.no/trygver/themes/mvc/mvc-index.html

  • https://beomy.tistory.com/43

  • https://velog.io/@eddy_song/mvc

  • https://blog.naver.com/jukrang/221414570067

  • https://academy.realm.io/kr/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/

  • https://ko.wikipedia.org/wiki/모델-뷰-컨트롤러

  • https://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference

댓글남기기

참고