MVC, MVP, MVPP

스프링 디스패쳐 서블릿을 생각해보자.
디스패쳐 서블릿은 서블릿이 1개인 것임.

우선 스프링 디스패쳐 서블릿이 아니라 그냥 서블릿을 사용한다고 생각해보자.
그냥 서블릿은 URL의 매핑을 클래스로 해야 하기 때문, 각각에 URL의 그룹핑을 할 수가 없다. = 공통처리 불가능, 예를들어 user/moneyInfo, user/scoreInfo 등을 각각의 url이 매핑되는 2개의 클래스를 만들어야함.
이렇게되면 단점은 user라는 것의 공통처리 로직을 한 곳에 모아둘수가 없음.... (단일책임의 원칙에도 위배될듯 함)

그래서 프론트 뭐시기 패턴으로 공통 관문을 만들어버림. -> 결국 이게 스프링 디스패쳐 서블릿

스프링에서는 @Controller라는 어노테이션을 붙여서 class User라는 컨트롤러를 만들고...
그래서 user로 시작하는 url은 User 클래스를 거치게 되면서 필요한 공통로직을 수행하고
그 안에 @RequestMapping(moneyInfo), @RequestMapping(scoreInfo)메쏘드를 url에 매핑되는 작업을 수행한다.
이때 일반적으로 스프링은 controller -> service(-> repository) 를 통해 Model을 만들고,
결정적으로 어느 View를 return할지 정해주니깐..
Controller의 사전적 의미가 맞다. 제일 핵심은, Controller는 모델(데이터)를 가공하고, 어느 View를 갱신할지 선택해주는 것이다.
(View가 갱신되는 방법으로는 model에서 호출할수도있고, view가 model의 변경을 polling하고 있을수도 있고, Controller또는 다른곳에서 view에게 갱신을 요청할수도 있다. 딱히 정의된건 없는듯하다. 스프링에서는 contrlloer의 메쏘드가 리턴하는 이름을 보고 뷰리졸버가 선택해준다.)
어쨋든 핵심은 Controller는 들어온 요청에 따라 필요한 모델을 가공하고, 어느 View를 갱신해줄지 정하는 녀석이다. 그리고, 요청으로 들어오는 View != 요청처리후 갱신할 뷰 상태인 것이다!


그리고 MVP(presenter) 패턴이란..
요청이 들어오는 UI View == 요청처리후 갱신할 View 이상태이다.
그래도 View의 역할을 단일책임으로 분리하기 위해 view에서 모델을 가공하는게 아니라, view로 요청이오면 모든 데이터를 Presenter로 넘겨버린다.
presenter는 view로부터 넘겨받은 데이터로 필요한 모델을 만들고, view의 화면을 업데이트 시키는 역할을 한다. (presenter가 중간에서 view의 화면갱신을 시켜버리는것!)
당연히 mvp패턴에서 view의 갯수만큼 presenter의 갯수가 증가한다.  view갯수 == presenter 갯수

그리고 더 나아가서 MVVM 패턴이란 (View Model)...
위의 mvp의 단점은 view의 갯수가 늘어나는 것만큼 presenter의 갯수도 동일하게 늘어난다.
근데 설계를 하다보니 view는 생김새는 거의 비슷해서 view에 매칭되는 presenter가 하는일이 거의 동일하더라...
불필요하게 presenter를 여러개 만드는것이 소모값이 크다 느껴서..
여러 view들이 단 1개의 viewModel을 이용하게 하는 것임. (추상화를 잘해야함)
이때 핵심은 viewModel은 view를 의존하지 않음. view로부터 전달받은 데이터를 가지고 model에서 데이터 가공만 하는것임. (viewmodel은 커맨드와 데이터바인딩을 가진다고 하는데 무슨말이지)
그렇다면 어떻게 view의 화면이 업뎃이 되냐..? mvp에서는 presenter가 view에게 갱신을 요청했는데..
mvvm에서는 view가 view model에게 데이터를 넘기고, 그 데이터의 변경을 감지하고 있음(polling) viewmodel이 모델을 만들면, view는 이것을 감지하고 화면을 업데이트 하는 방식임.
mvvm 단점은 설계가 좀 빢새짐.