MVC 패턴을 사용해야하는 이유는 무엇입니까?

요즘 웹 애플리케이션을 사용하는 모든 사람들이 모든 것에 MVC를 사용하고 싶어하는 것 같습니다. 그러나이 패턴을 사용하도록 설득하기가 어렵다는 것을 알게되었습니다. 백엔드 논리를 프로그램을 나타내는 프론트 엔드와 분리하는 것이 일반적인 아이디어라는 것을 이해합니다. 일반적으로 뷰는 항상 어느 정도 컨트롤러에 의존하는 것으로 보이며 이는 모델에 따라 다릅니다. 컨트롤러를 추가하면 어떤 이점이 있는지 알 수 없습니다. "응용 프로그램을 설계해야하는 방식"에 대한 과대 광고를 읽었지만 여전히 어디로 가야하는지 이해하지 못할 수도 있습니다. 내가 MVC에 대해 다른 사람들과 이야기 할 때마다 모든 사람들이 어떤 범주에 속하는지 다른 아이디어를 갖는 것처럼 보입니다.

그렇다면 왜 MVC를 사용해야합니까? 백엔드 로직에서 프론트 엔드를 분리하는 것보다 MVC를 사용하면 어떤 이점이 있습니까? (이 패턴에 대한 대부분의 "이점"은 인터페이스를 구현에서 분리하여 얻을 수 있으며 별도의 "컨트롤러"를 갖는 목적을 설명하지 못합니다)

허. Martin Fowler는 MVC에 대한 혼란에 동의합니다.

나는 MVC를 아주 다른 아이디어를 포함하고 있기 때문에 패턴으로 생각하는 것이 굉장히 유용하지 않다. 다른 장소에서 MVC에 대해 읽는 다른 사람들은 다른 아이디어를 취하여이를 'MVC'라고 설명합니다. 이것이 충분한 혼란을 유발하지 않으면 중국 속삭임 시스템을 통해 발전하는 MVC의 오해의 효과를 얻습니다.

그러나 그는 MVC에 동기를 부여하는 것에 대한 더 확실한 설명 중 하나를 계속 제시합니다.

MVC의 핵심은 분리형 프레젠테이션입니다. 분리 된 프리젠 테이션의 개념은 실제 세계에 대한 인식을 모델링하는 도메인 객체와 화면에 표시되는 GUI 요소 인 프리젠 테이션 객체를 명확하게 구분하는 것입니다. 도메인 개체는 완전히 독립적이어야하며 프레젠테이션을 참조하지 않고 작동해야하며 동시에 여러 프레젠테이션을 지원할 수 있어야합니다.

Fowler의 전체 기사를 여기 에서 읽을 수 있습니다 .

나는 이것이 당신이 다루고있는 문제에 크게 달려 있다고 생각합니다. 분리는 다음과 같습니다.

모델 -데이터를 어떻게 표현합니까? 예를 들어, 내 개체에서 DB와 같은 영구 저장소로 어떻게 이동합니까?- '사용자'개체를 데이터베이스에 어떻게 저장합니까?

컨트롤러 -내가 뭘? 이것은 일어나고있는 행동이며, 개념적 차원에서 수행되어야 할 것입니다. 예를 들어, 사용자에게 송장을 보내려면 어떤 단계를 거쳐야합니까? NB 이것은 많은 양의 객체에 영향을 줄 수 있지만 DB에 어떻게 유지되는지에 대해서는 아무것도 모릅니다.

보기 -결과를 어떻게 렌더링합니까?

내가보고 있다고 생각하는 문제는 많은 웹 응용 프로그램이 DB에 대한 영광스러운 CRUD (Create-Retrieve-Update-Delete) 인터페이스라는 것입니다. 즉, 컨트롤러에 '사용자 추가'를 지시 한 다음 모델에 '사용자 추가'를 지시합니다. 아무것도 얻지 못했습니다.

그러나 수행하는 작업이 모델의 변경 사항에 직접 적용되지 않는 프로젝트에서 컨트롤러를 사용하면 훨씬 쉽게 시스템을 유지 관리 할 수 ​​있습니다.

해서는 안됩니다.

다시 말하겠습니다. 논리를 뷰와 분리하는 아키텍처를 사용해야합니다. 필요한 경우 모델에 꼭 맞을 필요가없는 논리 (예 : 트리 탐색 구문 분석 URL 청크)가있는 경우 컨트롤러 (예 : MVC)를 사용하는 아키텍처를 사용해야합니다.

CI와 Yii에서 온 전용 컨트롤러를 사용하는 것이 정말 멋진 아이디어라고 생각했습니다. 그러나 적절한 RESTful 인터페이스로 애플리케이션을 개발할 때 컨트롤러가 비 모델 별 로직을 처리해야 할 필요성이 줄어드는 것 같습니다. 따라서 Django로 이동 한 다음 피라미드 (MVC 아키텍처를 완전히 따르지 않음)로 옮길 때 컨트롤러가 실제로 구축중인 응용 프로그램에 필요한 구성 요소가 아니라는 것을 알았습니다. 두 프레임 워크 모두 피라미드의 URL 디스패치와 같은 "컨트롤러"기능을 가지고 있지만, 런타임 요소 (예 : Cii의 Yii)가 아니라 구성 요소입니다.

하루가 끝나면 실제로 중요한 것은 논리와 견해를 분리하는 것입니다. 이를 통해 구현 측면에서 정리할 수있을뿐만 아니라 FE / BE 엔지니어가 동시에 작업 할 수 있습니다 (팀 환경에서 작업 할 때).

(측면 참고 : 전문적으로 웹앱을 개발하지 않아서 빠진 것이있을 수 있습니다)

그렇습니다. 이것에 대한 용어는 엉망입니다. 누군가 가 그 용어에 의해 의미 하는 바를 전혀 이해하지 못하기 때문에 이야기하기가 어렵습니다 .

별도의 컨트롤러 인 이유는 사용중인 컨트롤러의 버전에 따라 다릅니다.

테스트를 실행할 때보기에 작성하지 않았고 테스트하고 싶지 않은 많은 위젯이 있기 때문에 컨트롤러가 필요할 수 있습니다. 그렇습니다. 구현과 상속을 분리했기 때문에 스텁이나 모의 객체를 사용하여 다른 것을 테스트 할 수는 있지만 구체적인 견해 자체를 테스트하는 것은 더 어렵습니다. 동일한 코드를 실행하는 위젯 이없는 컨트롤러가있는 경우 직접 테스트 할 수 있으며 스크립트를 통해 위젯을 테스트 할 필요가 없습니다.

다른 버전은 IMHO가 구체적인 이점을 보여주기가 더 어렵습니다. 나는 그것이 GUI에 적용되지만 비즈니스 모델의 일부가 아닌 로직과 순수한 시각적 GUI 관심사를 분리하는 것입니다 (위젯이 보이는 모델의 업데이트를 번역하는 것과 같은). 그러나 실제로 두 클래스는 인터페이스를 통해 통신하더라도 너무 견고하게 결합되어 뷰를 병합하는 데 지나치게 화가 나기 어렵고 기능을 더 재사용 할 수있는 방법을 주시합니다. 그들이 분리 된 경우.

간단히 말해서 우려의 분리. "올바른"일을하고 코드를 깨끗하게하는 등의 모든 이야기 외에도 MVC를 사용하면 코드를 더 쉽게 재사용 할 수 있습니다. 기본적으로 모델과 컨트롤러를 프로그래밍하면 웹 앱, 데스크 앱, 서비스 등 어디에서나 별다른 노력없이 사용할 수 있습니다.

MVC 구조를 사용하는 기본 이유는 산업 환경에서 나타나며, 단일 작업 프로세스, 단일 모델을 사용하여 모든 응용 프로그램을 개발합니다. 따라서 프로젝트가 조직의 한 모듈에서 다른 모듈로 이동하는 경우 작업 시나리오를 더 잘 이해하는 것이 훨씬 쉽습니다. 작업의 명확성을 통합합니다.
개인은 신청에 대해 다른 접근 방식을 가지지 만, 직원과 결합 된 방식으로 작업 할 때는 먼저 두 사람 (귀하와 귀하의 직원)이 공통적으로 동의 한 모델에 대해 논의하고 착수합니다. 이러한 경우, 귀하와 귀하의 직원에게 할당 된 책임을 각각 별개의 여백으로 분리합니다.

MVC는 관리자 인 이론가들에 의해 유행어로 사용되는 것 같습니다. 그러나 HTML5가 널리 사용되는 반응 형 디자인으로 웹을 반복하고 웹과 iPhone에서 작동하는 단일 데이터베이스 프로그래밍 행을 만들려고 시도하는 것은 MVC의 일반적인 아이디어에 적합합니다. 웹 프론트 엔드 기술은 문자 그대로 서버 속도가 달팽이 속도로 움직이고있는 반면 CSS 제어의 새로운 반복 인 Jquery를 사용하여 문자 그대로 빛의 속도로 움직이고 있습니다.

결국 서버의 모든 것은 실제로 데이터를 프런트 엔드로 펌핑하는 서비스 또는 "애플릿"일 뿐이며 어떤 종류의 클라이언트가 있는지에 따라 해당 데이터가 다르게 소비되고 표시됩니다. 그런 의미에서 MVC는 의미가 있습니다.

이와 관련하여, 나는 현재 현실에서 MVVM은 실제로 더 나은 "패턴"이거나 컨트롤러보다 뷰를 변경하기 위해 항상 모델로 돌아 가야하기 때문에 컨트롤러보다 호출하고자하는 것입니다. . MVVM 패턴에서 ViewModel은 뷰를 즉시 업데이트 할 수 있습니다. 또한 MVVM 모델은 RESTful 설계 주체 IMHO를 촉진합니다.