사용자에게 보여지는 서비스를 개발함에 있어서 View
라는 부분은 필연적으로 존재하게 된다. 그리고 이 View
를 어떻게 어떤 방식으로 보여줄 것인지 그리고 어떤 방법이 유지 보수에 유리한지 등을 잘 신경쓰면서 개발해야 한다.
만약 프로덕트의 규모가 커져서 새로운 기능의 도입을 하거나 또는 유지 보수를 하거나 Testable
하게 개발하려면 아키텍처의 각 부분이 독립적으로 작동해야만 한다. 그래야만 각 부분들의 input과 output이 깔끔하게 정해져서 테스트하기 쉬우며 다른 기능에 붙이는 것도 다른 기능을 붙이는 것도 쉬워지기 때문이다. 이렇게 개발함으로서 클린 아키텍처를 적용했다고 할 수 있다. 지금부터 대표적으로 사용되어 왔던 View
를 포함한 개발 방식에 대해 알아보려고 한다.
가장 많이 사용되어 온 방식이며 아직도 많이 사용하는 방식이다. Model
, View
, Controller
를 가지며 먼저 각자의 개념부터 간단히 알아보자.
모델은 데이터베이스 또는 리포지토리 안의 데이터의 형태를 의미한다. 학생 모델이 있다면 그 모델은 키, 학교이름, 성별, 나이 등을 가진다고 할 수 있겠다.
뷰는 보여지는 화면을 의미하게 된다.
MVC의 핵심 개념으로 모든 input 요청을 받고 그 요청을 처리하고 Model
에 따라 어떤 뷰를 어떻게 보여줄지도 전부 처리하게 된다. View
와 Model
은 Controller
에게 어떤 요청도 하지 않고 전부 Controller
가 처리해서 보내준다.(아래 그림에서 뻗어 나가는 화살표 방향을 잘 보면 된다.)
모든 처리를 Controller
가 혼자 떠맡아 함으로서 하나의 컨트롤러가 여러개의 뷰를 가질 수 있다. 일반적으로 웹 개발에서 템플릿 엔진을 가지는 방식은 거의 MVC 방식을 따른다. 이 방식은 View
는 Model
의 형태에 따라서 보여지므로 서로 의존적인 관계에 있으며 Controller
가 모든 로직을 떠맡기 때문에 테스트를 하기도 쉽지 않다.
MVP 방식에서 P는 Presenter
를 의미하게 된다.
Presenter
는 뷰로부터 input을 받아서 로직을 처리한 후 그 뷰가 어떻게 보여질지 알려준다.
MVC에서는 뷰를 그리는 것도 Controller
가 담당했지만 MVP에서 Presenter
는 View
의 인스턴스만을 가지고 들어오는 input을 처리한 다음 돌려준다. 화살표 방향을 보면 View
가 Presenter
에게 input이 이렇게 들어왔음을 알리고 그 처리를 Presenter
가 Model
을 통해 작업하여 돌려준다.
결국 모든 View
는 하나의 Presenter
를 가져야 한다. 이 방식은 View
와 Model
사이의 의존성을 없애주기 때문에 위에서 말했던 독립적이라는 부분을 만족하게 된다.
그리고 Presenter
의 input과 output이 정해지므로 Testable
한 객체가 되었다고 할 수 있다. 하지만 이 방식은 View
와 Presenter
가 1대1로 존재해야 하므로 모든 View
마다 Presenter
를 만들어주어야 하고 이 둘 사이에 강한 의존성이 생기게 된다.
MVVM 방식에서 VM은 View Model
을 의미하게 된다.
View Model
은 View
에 보여질 데이터를 처리하고 가지고 있기만 한다. View
로 부터 input이 들어오면 그 데이터를 처리한 형태의 View Model
을 들고만 있고 View
가 꺼내서 보여주게 되는 방식이다. 이 방식은 View
에서 데이터 바인딩을 통해서 View Model
에 있는 값만 보여주게 되므로 View
와 View Model
의 의존성을 완벽하게 없앨 수 있다.
그리고 하나의 View Model
은 여러 개의 View
에서 접근할 수 있게 된다. 따라서 View
와 View Model
은 다대일의 관계를 가지게 된다.
이 방식에서 View Model
은 Testable
하게 되며 각각 독립적으로 작동하게 된다. 즉 유지보수가 쉬워지고 새로운 기능을 추가하기에 굉장히 용이한 방법이다.