MVC 또는 MVP 패턴 – 차이점은 무엇입니까?

수년 동안 저는 많은 개발자들에게 디자인 패턴과 모범 사례 사용에 대해 멘토링했습니다. 계속해서 반복해서 제기되는 한 가지 질문은 MVC(Model View Controller)와 MVP(Model View Presenter) 패턴의 차이점은 무엇입니까?

놀랍게도 대답은 당신이 생각하는 것보다 더 복잡합니다. 많은 개발자들이 두 패턴 중 하나를 사용하는 것을 꺼리는 이유 중 하나는 차이점에 대한 혼란 때문입니다.

차이점을 파헤치기 전에 패턴이 작동하는 방식과 둘 중 하나를 사용할 때의 주요 이점을 살펴보겠습니다. 두 패턴(MVC 및 MVP) 모두 몇 년 동안 사용되어 왔으며 UI와 비즈니스 계층 간의 문제 분리라는 핵심 OO 원칙을 해결합니다. JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory 및 최근에 발표 된 ASP.Net MVC 프레임 워크를 포함하여 이러한 패턴을 기반으로​ 하는 많은 프레임 워크가 오늘날 사용됩니다.

Model View Controller (MVC) Pattern

MVC 패턴은 UI(뷰)와 비즈니스 계층(모델)을 분리하는 데 중점을 둔 UI 프레젠테이션 패턴입니다. 이 패턴은 책임을 세 가지 구성 요소로 구분합니다. 뷰는 UI 요소를 렌더링하고, 컨트롤러는 UI 작업에 응답하고, 모델은 비즈니스 동작 및 상태 관리를 담당합니다. 대부분의 구현들에서, 세 개의 컴포넌트들 모두는 서로 직접 상호작용할 수 있으며, 일부 구현들에서, 제어기는 어떤 뷰를 디스플레이할 것인지를 결정할 책임이 있다(Front Controller Pattern).

Model View Presenter (MVP) Pattern

MVP 패턴은 MVC 패턴의 개념을 기반으로 하는 UI 프레젠테이션 패턴입니다. 이 패턴은 네 가지 구성 요소로 책임을 구분합니다. 보기는 UI 요소를 정렬하고, 보기 인터페이스는 프레젠테이션과 뷰의 연결을 느슨하게 결합하는 데 사용되며, 발표자는 뷰/모델 간의 상호 작용을 담당하고, 모델은 비즈니스 동작 및 상태 관리를 담당합니다. 일부 구현에서 발표자는 서비스(컨트롤러) 계층과 상호 작용하여 모델을 검색/유지합니다. 보기 인터페이스 및 서비스 계층은 일반적으로 발표자와 모델에 대한 단위 테스트를 더 쉽게 작성하는 데 사용됩니다.

Key Benefits

패턴을 사용하기 전에 개발자는 패턴 사용의 장단점을 고려해야 합니다. MVC 또는 MVP 패턴을 사용하면 여러 가지 주요 이점이 있습니다(아래 목록 참조). 그러나 고려해야 할 몇 가지 단점도 있습니다. 가장 큰 단점은 복잡성과 학습 곡선이 추가된다는 것입니다. 패턴은 간단한 솔루션에 적합하지 않을 수 있습니다. 고급 솔루션은 패턴을 사용하여 큰 이점을 얻을 수 있습니다. 제 경험에 따르면 몇 가지 솔루션이 많은 양의 복잡성을 제거하지만 두 패턴 중 하나를 사용하도록 리팩토링되는 것을 보았습니다.

• 느슨한 결합 – 프리젠터/컨트롤러는 UI 코드와 모델 사이의 중개자입니다. 이렇게 하면 뷰와 모델이 서로 독립적으로 발전할 수 있습니다.
• 우려 사항/책임의 명확한 분리

o UI (양식 또는 페이지) – UI 요소 렌더링 담당

o 발표자/컨트롤러 – UI 이벤트에 반응하고 모델과 상호 작용하는 역할을 합니다.

o 모델 – 비즈니스 행동 및 상태 관리에 대한 책임

• 테스트 구동– 각 주요 구성 요소(UI, 프레젠터/컨트롤러 및 모델)를 격리하면 단위 테스트를 더 쉽게 작성할 수 있습니다. 이는 인터페이스를 사용해서만 뷰와 상호 작용하는 MVP 패턴을 사용할 때 특히 그렇습니다.
• 코드 재사용– 우려 사항/책임 있는 디자인 접근 방식을 분리하면 코드 재사용을 늘릴 수 있습니다. 이는 완전한 도메인 모델을 사용하고 모든 비즈니스/상태 관리 논리를 해당 모델에 속한 위치에 유지할 때 특히 그렇습니다.
• 데이터 액세스 숨기기– 이러한 패턴을 사용하면 데이터 액세스 계층에서 데이터 액세스 코드가 속한 위치에 데이터 액세스 코드를 배치해야 합니다. 데이터 액세스를 위해 일반적으로 MVP/MVC 패턴과 함께 작동하는 다른 여러 패턴이 있습니다. 가장 일반적인 두 가지는 저장소와 작업 단위입니다. (자세한 내용은 Martin Fowler – Patterns of Enterprise Application Architecture 참조)
• 유연성/적응성– 대부분의 코드를 프리젠터/컨트롤러 및 모델 구성 요소로 격리함으로써 코드 베이스가 변경에 더 잘 적응할 수 있습니다. 예를 들어, 지난 몇 년 동안 UI 및 데이터 액세스 기술이 얼마나 많이 변했는지, 그리고 오늘날 사용할 수 있는 선택의 폭이 얼마나 넓은지 생각해 보십시오. MVC 또는 MVP를 사용하여 적절하게 디자인된 솔루션은 다중 UI 및 데이터 액세스 기술을 동시에 지원할 수 있습니다.

주요 차이점

그렇다면 MVC와 MVP 패턴의 차이점은 무엇입니까? 사실, 그들 사이에는 많은 차이점이 없습니다. 두 패턴 모두 여러 구성 요소에서 책임을 분리하는 데 중점을 두고 비즈니스 계층(모델)에서 UI(뷰)를 느슨하게 결합하는 것을 촉진합니다.  주요 차이점은 패턴이 구현되는 방식이며 일부 고급 시나리오에서는 발표자와 컨트롤러가 모두 필요합니다.

패턴 간의 주요 차이점은 다음과 같습니다.

MVP Pattern

• 뷰가 모델에 더 느슨하게 결합됩니다. 발표자는 모델을 뷰에 바인딩할 책임이 있습니다.
• 뷰와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉽습니다.
• 일반적으로 보기 발표자는 일대일 매핑을 합니다. 복잡한 보기에는 여러 명의 발표자가 있을 수 있습니다.

MVC Pattern

• 컨트롤러는 동작을 기반으로 하며 보기 간에 공유할 수 있습니다
• 표시할 보기를 결정할 수 있음(Front Controller Pattern)

이 게시물이 흥미롭고 MVC와 MVP 패턴의 차이점을 명확히 하는 데 도움이 되었기를 바랍니다. 그렇지 않다면 낙담하지 마십시오.패턴은 때때로 사용하기 어려울 수 있는 강력한 도구입니다. 한 가지 기억해야 할 점은 패턴은 청사진이며 즉시 사용 가능한 솔루션이 아니라는 것입니다. 개발자는 이를 지침으로 사용하고 문제 도메인에 따라 구현을 수정해야 합니다.