단위 테스트가 MVC 패턴의 주요 목표입니까?

최근 인터뷰에서 질문 중 하나는 '우리는 왜 MVC를 사용합니까?'였습니다. 방금 실제 시스템이 얼마나 많은지에 더 가깝다고 대답했습니다! 유지 보수성, 확장 성 등에 관한 이점을 설명했습니다.

나는 그들의 주장이 타당하다는 것을 알고 있지만, 그것이 여전히 주된 이유인지 의심 스럽다. 왜냐하면 (i) Unit Testcases를 쓰지 않기로 결정하더라도 MVC는 가능한 선택이다. (ii) Unit Testcases가없는 많은 GUI 시스템은 MVC를 따르십시오.

문제는 '단위 테스트가 MVC 패턴의 주요 목표입니까?'입니다.

편집 : 나는 그들이 테스트 주도 개발 / NUnit 테스트 케이스 작성의 용이성을 언급 할 수 있다고 가정합니다. 모델에 대한 테스트 사례를 작성할 수 있기 때문입니다 (보기가 모델의 상태 변경을 정확하게 반영하는 경우). 잘못되면 수정하십시오.

모델, 뷰 및 컨트롤러가 모두 고유 한 책임을 가지므로 주요 목표는 "문제의 분리"입니다.

최초의 Xerox PARC 논문 의 저자는 다음과 같이 말합니다.

MVC의 기본 목적은 인간 사용자의 정신 모델과 컴퓨터에 존재하는 디지털 모델 간의 격차를 해소하는 것입니다.

단위 테스트가 주요 목표라면 뷰를 쉽게 단위 테스트 할 수 있습니다. 단위 테스트 프로젝트 / 프레임 워크의 조경을 살펴보면 주장과는 상당히 반대임을 알 수 있습니다. 하나는 일반적으로 통합 및 기능 테스트를 사용하여 뷰를 테스트하는 것입니다.

제 생각에는 그 대답은 확고한 '아니오'입니다. 아마도 이것이이 특정 조직에서 관찰 된 주요 이점 이었을지 모르지만,이를 '1 차 목표'라고 부르지는 않을 것입니다.

MVC를 구현하는 것이 어려운 것은 아니며, 단위 테스트는 어려울 정도로 어렵습니다 (처음-처음으로 수행 한 방식은 거의 테스트 할 수 없었습니다).

반면에 싱글 톤과 같은 것을 제외한 거의 모든 패턴이 디커플링을 촉진하기 때문에 단위 테스트를 용이하게한다고 말할 수 있습니다. 거의.

단위 테스트가 알려지기 전에 MVC (대부분의 알려진 디자인 패턴과 동일)가 진행되었습니다. GoF 서적은 1994 년에 출판되었으며 수십 년 전이나 수십 년 동안 사용 된 패턴 만 문서화하고있었습니다. (그리고 그 안에 단위 테스트에 대한 언급은 없습니다.) 단위 테스트에 관해서는, "공개"가 된 시점에 대한 정확한 시간을 찾을 수 없습니다. 나는 극단적 인 프로그래밍 관련 기사와 첫 번째 XP 책에서 개인적으로 읽었습니다. 1999 년에 나왔습니다.

따라서 단위 테스트는 패턴을 발명 / 문서화하는 주요 목표가 될 수 없었습니다. 패턴이 적절하게 적용되면 단위 테스트가 크게 용이 해졌다는 것은 공정합니다.

나는 단위 테스트의 용이함이 장점 중 하나라고 생각하지만 MVC를 사용할 때의 이점 중 일부는 나열된 이유와 함께 있습니다. MVC를 사용해야하는 주된 이유가 하나 있다는 것은 실수입니다. 문제의 회사가 단위 테스트를 용이하게하기 위해 MVC를 선택하는 것처럼 들리므로 이것이 주요한 이유라고 생각합니다. 개인적으로 MVC를 사용하는 이유는 웹 양식과 비교하여 단순하기 때문에 설계 및 유지 관리가 쉬워 지지만 모든 개인 / 회사는 기술을 사용해야하는 고유 한 이유가 있습니다.

ASP.NET MVC 세계에서는 ASP.NET에 대한 많은 개선 사항이 프레임 워크 자체에 포함되었습니다. 이 디자인 패턴의 주요 목적은 더 나은 유지 관리 성, 개선 된 테스트 가능성 및 응용 프로그램의 깔끔한 구조에 중점을두기 위해 비즈니스 로직을 사용자 인터페이스에서 분리하는 것입니다.

ASP.NET MVC에는 다음 중 하나 이상이 필요한 경우 선택할 수있는 최상의 옵션이되는 특정 기능이 있습니다.

• 생성 된 HTML에 대한 높은 수준의 제어 : Web Forms와 달리 ASP.NET MVC의 Views는 사용자가 지시 한대로 HTML을 렌더링합니다. 최근에이 영역에서 Web Forms가 개선되었지만 여전히 MVC의 제어 수준이 없습니다.

• 더 쉬운 단위 테스트 : ASP.NET MVC, 그것은 매우 쉽게 같은 테스트 주도 개발 (TDD)와 같은 패턴을 테스트 따르는 것입니다. Web Forms의 복잡한 이벤트 수명 주기로 인해 컨트롤 기반 프레임 워크에서 MDD를 사용하면 TDD가 훨씬 더 쉽습니다.

• 우려의 분리 : 시스템의 모든 측면이 명확하게 분리되어 있음을 나타냅니다. 구현하는 패턴으로 인해 MVC 응용 프로그램은 불연속 및 느슨하게 바인딩 된 부품 (모델, 뷰 및 컨트롤러)으로 나뉘어 유지 관리가 쉽습니다.

다른 장점 중 일부는 다음과 같습니다.

• MVC 패턴 자체는 애플리케이션의 기능을 모델, 뷰 및 컨트롤러의 세 가지 핵심 부분으로 명확하게 분리하여 복잡성을보다 쉽게 ​​관리 할 수 ​​있습니다.

ASP.NET MVC 웹 응용 프로그램은 뷰 상태 또는 서버 기반 양식을 사용하지 않습니다. 따라서 MVC 프레임 워크는 응용 프로그램의 동작을 완전히 제어하려는 개발자에게 이상적입니다. 보기 상태가 매우 커질 수 있으며 이는 느린 네트워크에서 실행되는 스마트 폰과 같은 장치에서 문제가됩니다 (모든 정보를 전송하는 것이 매우 느릴 수 있음). Web Forms 페이지에서는 페이지 당 하나만 가질 수 있습니다. 이것은 상당히 큰 제약입니다. MVC에는 그러한 제한이 없습니다. 즉, 원하는만큼 요소를 가질 수 있습니다.

ASP.NET MVC는 TDD (Test-Driven Development)를보다 잘 지원합니다.

ASP.NET MVC는 대규모 개발자 팀이 지원하는 웹 응용 프로그램과 HTML에 대한 높은 수준의 제어가 필요한 웹 디자이너에 적합합니다. ASP.NET MVC 요청 처리