코드스쿼드에 마스터즈 코스를 진행하는 과정 중 JavaScript 로 간단한 MVP를 구현하면서 느낀점을 기록한 글 입니다

서론

MVP 를 알게 된 것은, 코드스쿼드에서 MVC로 특정 프로젝트를 구현하면서 알게되었다.

강의 내용 중 Model과 View의 관계를 느슨하게 하면 좋다 라는 부분이 있었는데, 거기서 Presenter의 존재를 알 수 있었다.

그때까지는 무슨말인지 몰랐다. 그래도 일단 MVC를 적용한다고 적용했는데…

구현을 다 하고 나니 느껴지는 MVC의 단점은 Model과 View가 기가막히게 꼬인다는 것 (+Controller)

그리고 내가 잘못 구현한 부분 중 하나는 View를 명확하게 나눠놓지 않았다

View 를 기능 을 기준으로 나눠놓으니 이리 쓰이고, 저리 쓰이며

view view-update view-exception 등등… (알 수 없는 View들의 혼돈의 카오스)

그래서 굉장히 모호한 구조로 진행되다가 코드스쿼드 멘토(크롱)님이 공사(?)를 제안하셨다.

• 실제 화면을 바라보고(자판기를 바라보고) 동작의 경계점이 있는데 그걸 가지고 각각 view를 만들어보는거죠
• View 를 동작중심 으로 개편해보세요.
• 자세하게 나눠논 상태인데 뷰는 렌더링하는것에 초점을 맞춰보세요.

MVC 에서 Model과 View가 지긋지긋하게 얽혀있는 것을 보기가 싫어서 다른 패턴을 찾기 시작했다.

그래서 선택한 것이 MVP 패턴이다.

MVP, Presenter의 등장

MVP 는 딱 보기에도 View 와 Model 간 관계가 아예 없다 (이때까지만 해도 나에게 닥쳐올 시련을 잘 몰랐다)

Model 은 역할이 명확하다.

프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분

View 는 렌더링에 초점을 맞추면 된다.

사용자에게 제공되어 보여지는 UI 부분

Presenter

View에서 요청한 정보를 Model로 부터 가공해서 View로 전달하는 부분

MVP 는 Model과 View의 관계가 존재하지 않는 대신, 해당 작업들을 Presenter 가 담당한다.

• View 가 Presenter 에게 작업 요청 (데이터가 필요해!)
• Presenter 는 해당 요청에 맞는 Model 에게 데이터 요청
• Presenter 가 데이터를 다시 View 에게 반환
• View 는 Presenter 에게 받은 데이터를 가지고 렌더링

Class 구조도

객체간의 의존되는 것을 대략 시각적으로 표시해볼래요? A,B,C 클래스가 있다고치고, 서로 의존하는 상태를 대략 종이에라도 표현해보면서 어떤 클래스가 어떤 메서드를 부르는지 정리해보세요. 혹시 상호 의존하는 건 없는지도 살펴보고요.