디자인패턴과 뷰패턴 6회차 - ChoDragon9/posts GitHub Wiki
MVC
MVC 패턴은 디자인 패턴에서 컴포지트 패턴이라고 한다. 디자인 패턴의 궁극적인 목적은 컴포지트 패턴을 만드는 것이다. 컴포지트 패턴은 유명하게 사용되는 경우가 없으나 유명해진 경우 자주 사용된다. 컴포지트화 되어 있어도 패턴으로 인식되는 경우는 극히 드물다. 디자인 패턴은 기본적인 골격을 이루고 디자인 패턴을 모아 컴포지트 패턴이 만들어 진다. 패턴을 배우는 이유는 많은 시간과 노력이 들어간 연구의 결과이기 때문이다.
MVC는 역사상 두가지가 있다. 첫번째는 모델-뷰가 적극적으로 통신하는 MVC가 있고, 두번째인 현대는 컨트롤러를 중심으로 모델의 데이터를 뷰에게 전달한다. 컨트롤러는 모델과 직접적인 관계이다. 모델은 컨트롤러를 모르고 컨트롤러는 모델을 생성하는 책임이 있다. 모델은 순수한 데이터 원형을 이야기한다. 모델은 변화가 일어났을 때 컨트롤러에게 알려준다. 결합도를 줄이기 위해 옵져버 패턴으로 모델과 컨트롤러가 연결되어 있다. 컨트롤러는 뷰도 생성한다. 컨트롤러는 뷰에게 모델에게 받은 데이터를 전달한다. 뷰는 모델에 기반하여 렌더링 처리한다. 뷰에게 사용자 입력의 처리를 컨트롤러에게 위임을 한다. 컨트롤러는 뷰에게 위임받은 액션을 대신 처리하게 되고 모델에게 데이터 요청을 하게 된다.
그럼 누가 컨트롤러를 생성할까. 컨트롤러의 생성은 라우터에서 하게된다. 상황에 따라 컨트롤러를 생성한다. 라우터에 따라 동작해야 하는 역할을 결정하여 컨트롤러를 생성하게 된다. 모델과 뷰가 분리된 이유는 변화율이 다르기 때문에 두가지를 분리한다.
현대의 MVC패턴의 컨트롤러는 책임이 많기 때문에 컨트롤러 볼륨이 커진다. 이것은 MVC의 단점이기도 하다. 이 부분을 해결하기 위해서는 컴포넌트로 분리한다. 컨트롤러를 컴포넌트로 분리하여 볼륨을 작게 만든다.
뷰를 만들 때는 굉장히 광활하다. 컨트롤러가 순수한 데이터를 뷰에게 전달하기 때문이다. 프런트 엔드 개발할 때는 순수한 데이터를 뷰에게 표시하는 역할에 비중이 크고, 백 엔드 개발할 때는 모델의 비중이 크다.
컨트롤러는 라우터를 알고 있다. 그 이유는 컨트롤러가 다른 컨트롤러에게 일을 시킬 때 필요하다. 컨트롤러를 다른 컨트롤러를 모른다. 그렇기 때문에 라우터를 통해서 컨트롤러를 찾아달라고 요청하게 된다. 라우터는 역할에 맞는 컨트롤러를 상태로 가지고 있다. 필요할 때 해당 컨트롤러를 실행해준다.
컨트롤러는 모델을 생성하고 청취한다. 그리고 뷰를 생성한다. 컨트롤러에서 모델의 변경을 감지하면 뷰에게 새로 렌더링하도록 요청한다. 컨트롤러는 본인의 역할이 아는 것은 라우터를 통해 컨트롤러를 요청한다.
현대의 컨트롤러와 뷰는 1:1관계이다.
MVVM
MVC에서 파생되는 패턴들은 모델과 뷰 사이에 무언가를 넣는 것이다. 뷰를 가상화하는 프록시를 가짐으로서 뷰와 모델간의 관계를 끊는 다. 모델의 데이터 형태가 뷰에게 의존이 생기기 때문에 모델의 변경이 필요할 때는 뷰까지 변경이 이뤄짐으로 변경을 할 때 비용이 많이 든다. 그래서 모델의 데이터 형태와 뷰 렌더링을 위한 데이터 형태를 분리하기 위해 객체를 만들어서 의존성을 해결한다. 뷰를 위한 데이터이기 때문에 뷰모델이라고 부른다. 뷰와 뷰모델은 양방향 바인딩이 이뤄진다. 뷰와 뷰모델은 변경이 되었을 때 서로 변경이 됬음을 알려준다.