MVC에 비해 MVP의 개선점은 무엇입니까?

3 일 동안 MVC (Model-View-Controller) 및 MVP (Model-View-Presenter) 패턴에 대해 읽었습니다 . 그리고 나를 매우 귀찮게하는 한 가지 질문이 있습니다. MVC가 이미있을 때 소프트웨어 설계자가 MVP를 발명 한 이유는 무엇입니까?

MVC가 해결하지 못했거나 심하게 해결되지 않았지만 MVP가 해결할 수있는 문제는 무엇입니까? MVP는 어떤 문제를 해결하려고합니까?

MVP의 역사와 설명 또는 MVC와 MVP의 차이점에 대한 많은 기사를 읽었지만 내 질문에 대한 명확한 대답은 없었습니다.

내가 읽은 기사 중 하나에서 다음과 같이 말했습니다.

이제 Model View Presenter는 최신 컴포넌트 기반 그래픽 사용자 인터페이스에 적용 할 때 MVC 패턴의 부적합에 대한 응답이었습니다. 최신 GUI 시스템에서 GUI 구성 요소 자체는 일부 중앙 컨트롤러가 아닌 마우스 이동 및 클릭과 같은 사용자 입력을 처리합니다.

그래서 이해할 수는 없지만 실제로 GUI 구성 요소가 사용자 입력을 직접 처리하지 못하는 다른 방법이 있습니까? 그리고 "자체 취급"이란 정확히 무엇을 의미합니까?

MVC는 개념적으로 우아합니다.

• 사용자 입력은 컨트롤러에 의해 처리됩니다
• 컨트롤러가 모델을 업데이트합니다
• 모델이보기 / 사용자 인터페이스를 업데이트합니다

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

그러나 MVC의 데이터 흐름과 이벤트 흐름은 순환 적입니다. 그리고 뷰에는 종종 사용자 로직을위한 이벤트 핸들러와 같은 중요한 로직이 포함됩니다. 이러한 특성으로 인해 시스템을 테스트하기 어렵고 유지 관리하기가 어렵습니다.

MVP 아키텍처는 컨트롤러를 발표자와 교체하여 뷰와 모델을 중재합니다. 이것은 시스템을 선형화합니다.

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

다음과 같은 장점이 있습니다.

• 논리 (이벤트 핸들러 및 사용자 인터페이스 상태와 같은)를보기에서 발표자로 이동할 수 있습니다.

• 사용자 인터페이스는 사용자 인터페이스 상태를 설명하므로 발표자 관점에서 단위 테스트를 수행 할 수 있습니다. 단위 테스트 내에서 뷰를 발표자를 호출하는 테스트 드라이버로 바꿉니다.

• 사용자 인터페이스는 애플리케이션 로직과 분리되어 있기 때문에 둘 다 독립적으로 개발할 수 있습니다.

그러나이 방법에는 몇 가지 단점이 있습니다.

• 더 많은 노력이 필요합니다.
• 발표자는 유지 관리 할 수없는 "신 클래스"로 쉽게 변경할 수 있습니다.
• 응용 프로그램에는 단일 MVP 축이 없지만 여러 축이 있습니다. 사용자 인터페이스의 각 화면 / 창 / 패널마다 하나씩입니다. 아키텍처를 단순화하거나 지나치게 복잡하게 만들 수 있습니다.

MVP에서 발표자는 MVC의 컨트롤러를 대체합니다. 이 둘의 차이점은 발표자가 직접보기를 조작한다는 것입니다. 이 기능은 WV와 같은 MVVM 패턴에 적합한 풍부한 데이터 바인딩에 대한 강력한 지원없이 주로 이벤트 기반 (Windows Forms와 같은) UI 프레임 워크를 위해 설계되었습니다. 그렇지 않으면 뷰 상태를 관리하고 백업 모델을 업데이트하기위한 많은 논리가 뷰 자체에 있습니다.