기술을 이해하려면 그 기술 히스토리(문제점과 해결책)를 알면 명확해 진다.
전통의(?) MVC 부터 MVP, MVVM, CLEAN ARCHITECTURE, VIPER, … 등등 아키텍쳐 종류가 매우 많다. 인터넷에 찾아보면 뭐가 다르고 뭐가 좋다 하는 글들을 많이 볼 수 있다. 내가 볼 때는 다 거기서 거기였다. 그리고 최근 내가 선택한 것은 결국 MVC 였다.
MVC이전
GUI있기 전에 프로그램은 콘솔에서 동작했다. 데이터를 읽고, 처리하는 과정에서 print로 콘솔 로그를 출력했다. 혼재되는 출력을 구분하기 위해 stdout, stderr, stddev 로 구분했다. 개발자들 끼리만 보면 되니까 충분했다.
MVC
GUI시대가 되었다. 모든 결과는 즉각 화면을 통해 유저에게 전달된다. 유저의 행동을 항상 화면에 표현해 줘야 한다.
코드의 덩치가 점점 커지고, 복잡도가 증가했다. 데이터(M)와 출력(V)을 나누고, 그 사이에서 컨트롤러(C)를 두어 비지니스 로직을 처리했다. 잘 동작한다.
아쉬움
코드 생산성에서 퀄리티로 관점이 옮겨가면서 TDD라는 방식이 등장했다. MVC에 적용하려고 보니 실제 테스트해야 하는 대상인 비지니스 로직은 모두 C에 있다. 하지만 C는 V와 너무 얽혀있어 떼어내기가 어렵다. 테스트가 안된다!
MVP의 등장
C와 V를 분리하자. V가 GUI일수도 있지만 콘솔일 수도 있도록 바꿔치기 할 수 있게 하자는 아이디어!
인터페이스를 사이에 두고, C는 인터페이스만 호출하고 이 인터페이스를 구현한 V가 화면을 처리하게 한다. 이제 C를 테스트 할 수 있게 됐다. 그리고 이 C를 Presenter 라고 불렀다.
MVVM의 등장
C가 V에 표현하기 위한 인터페이스 증가. 대부분 반복되는 코드. 귀찮았다. 데이터 바인딩 기술 등장!
M과 V를 묶어버리자. V는 M의 변화를 감지하여 알아서 출력할 것이다. 그러니까 이건 VM 이다.
한걸음 물러서서
기존의 C 역할을 P가, 그리고 VM 이 하는 것일 뿐 C 로써의 역할은 같다.
어떻게 구조화 했는지에 대해 명시하기 위해서 이름만 바꿔 부를 뿐, 결국 MVC의 범주안에서 다를바 없다.
튜닝의 끝은 순정
MVP, MVVM, VIPER … 이런거 코드만 많아지고 연결도도 복잡해지고 한눈에 파악하기도 어렵다. 그냥 MVC를 잘 쓰자!
M
데이터 클래스와 데이터의 패치에 대한 코드만 담는다.
여러개의 파일/클래스로 구성
V
데이터 결과의 표현만 구현한다.
데이터 결과는 바인딩으로 얻어온다.
UIViewControler 또는
Activity/Fragment 로 한정
C
비지니스 로직만 담는다.
M으로 부터 얻은 데이터에 로직을 따르는 처리를 하고
결과를 바인딩에 보낸다.
여러개의 파일/클래스로 구성
그리고 바인딩에는 Rx를 쓴다