MVC 패턴
MVC(MODEL - VIEW - CONTROLLER)
애플리케이션을 삼분할 해서 모델 , 뷰 , 컨틀롤러 단으로 나눠서 구성요소에게 고유한 역활을 부여한 개발 방식입니다.
Model : 데이터와 관련된 책임을 담당하는 레이어
[POJO] 비즈니스 로직을 수행한다.
주로 상태 변화를 처리한다.
@Enttity (영속성에서 테이블에 매핑되는 클래스)가 주로 대상이다.
데이터와 행동을 갖는 객체이다.
View : 사용자에게 보일 사용자 인터페이스를 담당하는 레이어
- 웹에서는 웹 브라우저로 렌더링 되는 페이지가 해당된다.
- 모델이 처리한 데이터를 받아서 합산하고 사용자(클라이언트)의 브라우저로 렌더링 되는 페이지이다.
- 데이터, 로직은 없어야 한다.
- 동적으로 처리되어야 할 데이터를 시각화해준다.
- 상황과 도메인에 맞게 다른 값을 가져야 하는 데이터들에 대해서만 모델에서 받아온다.
Controller : Model과 뷰를 연결해주는 레이어이다.
- 컨트롤러는 사용자의 요청에 맞는 서비스를 실행하게 된다.
- 자바의 Spring에서는 DispatcherServlet으로 컨트롤러를 이해해야 한다.
- 상당히 많은 역할을 담당하게 되었고, 리플렉션 기반의 애너테이션 기법(AOP)으로 코드를 상대적으로 가볍게 처리할 수 있게 되었다.
- 처리한 모델의 값을 뷰에 전달해서 반환한다.
사용자의 요청(웹 브라우저로 들어오는 요청)을 가장 먼저 마주한다.
MVP 패턴
Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.
View : 사용자에서 보여지는 UI 부분이다.
Presenter : View에서 요청한 정보로 Model을 가공하여 View에 전달해 주는 부분이니다.
2) 동작
- 사용자의 Action들은 View를 통해 들어오게 됩니다.
- View는 데이터를 Presenter에 요청합니다.
- Presenter는 Model에게 데이터를 요청합니다.
- Model은 Presenter에서 요청받은 데이터를 응답합니다.
- Presenter는 View에게 데이터를 응답합니다.
- View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.
⭕ 장점
MVP 패턴의 장점은 View와 Model의 의존성이 없다는 것이다. MVP 패턴은 MVC 패턴의 단점이었던 View와 Model의 의존성을 해결하였다.
❌ 단점
MVC 패턴의 단점인 View와 Model 사이의 의존성은 해결되었지만, View와 Presenter 사이의 의존성이 높은 가지게 되는 단점이 있다.
어플리케이션이 복잡해 질 수록 View와 Presenter 사이의 의존성이 강해지는 단점이 있다.
MVVM 패턴
MVVM 패턴은 Model + View + View Model를 합친 용어다.
Model : 어플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분이다.
View : 사용자에서 보여지는 UI 부분이다.
View Model : View를 표현하기 위해 만든 View를 위한 Model이다.
(View를 나타내 주기 위한 Model이자 View를 나타내기 위한 데이터 처리를 하는 부분이다.)
2) 동작
- 사용자의 Action들은 View를 통해 들어오게 됩니다.
- View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달합니다.
- View Model은 Model에게 데이터를 요청합니다.
- Model은 View Model에게 요청받은 데이터를 응답합니다.
- View Model은 응답 받은 데이터를 가공하여 저장합니다.
- View는 View Model과 Data Binding하여 화면을 나타냅니다.
참고
https://fomaios.tistory.com/entry/Design-Pattern-MVP-%ED%8C%A8%ED%84%B4%EC%9D%B4%EB%9E%80
https://junhyunny.github.io/information/design-pattern/mvc-pattern/
