MVC의 몰락은 무엇입니까? [닫은]

몇 년 전에 코드를 실제로 구성하기 시작한 이래로 MVC / MV *를 사용해 왔습니다. 나는 그것을 오랫동안 사용하여 코드를 구성하는 다른 방법을 생각조차 할 수 없었으며 인턴이 된 후의 모든 작업은 MVC 기반이었습니다.

내 질문은 MVC의 몰락은 무엇입니까? 어떤 경우에 MVC가 프로젝트에 나쁜 선택이되고 어떤 것이 더 올바른 선택이됩니까? MVC 대안을 찾을 때 거의 모든 결과는 다른 유형의 MVC입니다.

범위가 좁아 져서 닫히지 않도록 웹 응용 프로그램을 예로 들어 보겠습니다. 다른 프로젝트에 대해 백엔드 및 프론트 엔드에서 작업하므로 프론트 엔드 또는 백엔드 만 말할 수는 없습니다.

MVC는 UI 관련 패턴입니다. 복잡한 응용 프로그램을 구축하는 경우 MVC 삼중 항에서 다른 클래스, 하위 시스템 또는 계층으로 UI와 관련이없는 모든 것을 가져와야합니다.

나의 가장 큰 실수였다. 나는 그 간단한 규칙을 이해하는 데 오랜 시간을 보냈습니다.

• 전체 애플리케이션에 MVC 패턴을 확산시키지 마십시오.
• UI 관련 항목으로 만 제한하십시오.

작성한 코드가 논리적으로 올바른 위치에 있는지 항상 확인하십시오. 즉, 해당 코드가 배치 한 클래스의 책임 영역에 논리적으로 맞는다는 의미입니다. 그렇지 않은 경우 코드를 이해하자마자 멀리 옮기십시오.

MVC 대체물이라고 부르는 모든 패턴 (예 : Model-View-Presenter, Model-View-ViewModel)은 일반적인 MVC 개념을 구현하는 방법 일뿐입니다.

내 의견으로는 MVC에는 두 가지 유형이 있습니다-순수하고 불결합니다 (더 나은 단어가 없기 때문에 :)

순수한 MVC는 작은 대화에 도입 된 것입니다.

개인 컴퓨팅 / 데스크톱 응용 프로그램을위한 것입니다. 보시다시피, 모델은 업데이트 / 변경 사항을 뷰에 알려줍니다. MVC에서는 (불완전한) 것은 아닙니다.

웹 애플리케이션을 위해 선전 된 다른 (불완전한) MVC는 위의 클래식 MVC 대신 PAC ( Presentation-abstraction-control ) 패턴에 가깝습니다. 그것은 코드 구성과 우려의 분리에 관한 것입니다.

• 모델 : 저장된 데이터의 추상화
• 제어 : 일반적으로 비즈니스 로직 계층이라고하는 것은 물론 HTTP 요청을 해당 비즈니스 로직 (일명 컨트롤러)으로 라우팅하는 응용 프로그램의 일부
• 보기 : 대부분 모델의 데이터를 형식화하여 클라이언트에 반환하는 템플릿을 봅니다. 모델은 절대로 업데이트를 뷰에 전송하지 않으며 뷰가 모델의 업데이트를 '구독'하지도 않습니다. 악몽과 연결될 것입니다. 따라서 실제 MVC보다 PAC와 비슷합니다.

이제 웹 애플리케이션이 일반적으로 구성되는 방법은 다음과 같습니다.

1. 프론트 엔드 : Backbone.js 등의 프레임 워크를 사용하는 클라이언트의 MVC. 본질적으로 '진정한'MVC 형식입니다.
2. 백엔드 : 코드 구성 및 우려 분리를위한 MVC / PAC가 있습니다.
3. 글로벌 웹 앱 (전체 웹 애플리케이션 용) : JSON 데이터 만 리턴하는 RESTful 백엔드가 있는 경우 View 및 Controller가 본질적으로 존재하는 프론트 엔드 클라이언트 애플리케이션 의 모델 로 전체 백엔드를 인식 할 수 있습니다 .

MVC의 단점은 무엇 입니까? 글쎄, 패턴은 시간의 시험을 견디어 왔기 때문에 조금 '복잡한'것보다 그다지 중요한 것은 많지 않습니다. MVC는 복합 패턴입니다. 전략 / 관찰자 패턴을 구현하며 모두 높은 수준의 패턴을 형성하도록 잘 정렬되어 있습니다.

어디서나 사용해야합니까? 아마. 매우 복잡한 웹 응용 프로그램이 여러 계층으로 분할 될 수 있습니다! View / Business Logic / Data 레이어만으로는 벗어날 수 없습니다. 중요한 프레임 워크 / 조직은 여전히 ​​MVC-ish 일 수 있지만 거시적 수준 일뿐입니다.

MVC 자체만으로는 나쁜 선택이 될 수있는 예는 다음과 같습니다 . 대형 은행을위한 항공 교통 관제 시스템 또는 대출 / 모기지 처리 응용 프로그램을 설계 해보십시오. MVC만으로는 나쁜 선택입니다. 필연적으로 이벤트 계층 / 메시지 대기열과 개별 계층 내에 MVC가 포함 된 다중 계층 구조 및 코드 기반을보다 잘 구성 할 수있는 중요한 MVC / PAC 설계가있을 수 있습니다.

많은 사람들이 디자인 패턴을 사용하는 실수는 그것이 한 곳에서 아름답게 작동하고 어디에서나 적용하려고 시도하는 것입니다.

한곳에서 한동안 일한 적이 있다면, 싱글 톤 / 의존성 주입 / TDD 등 당시 어떤 기술 / 디자인 패턴 / 실습이 유행했는지를 보면서 거의 코드 조각과 데이트 할 수 있습니다.

사용하지 않는 곳도. MVC 삼중 항의 한 요소가 적용되지 않는 경우 콘솔 응용 프로그램은 인터페이스를 전혀 구현하지 않을 수 있습니다. 유틸리티 프로그램에는 모델이 없을 수 있습니다. 그리고 모델이나 뷰가 없다면 컨트롤러가 필요하지 않습니다.

문제는 개념에서 거의 발생하지 않으며 구현에 대해서는 더 많이 발생합니다. 패러다임이 아무리 좋더라도 시간을내어 문제에 적합한 지 확인하십시오.

MVC는 개발 플랫폼에 없어서는 안될 패러다임과 같이 복잡성이 증가합니다. 단점은 분리되어서는 안되는 분리 된 클래스를 정리하고 클래스가 얼마나 밀접하게 묶여 있는지 명확성을 줄이는 것입니다. 또는 사소한 프로젝트의 경우 코드를 난독 처리하기도합니다.

첫 번째 문제의 대안은 그러한 코드를 독립적 인 하위 프로젝트로 분리하는 것입니다. 두 번째 대안은 클래스 또는 파일 모델에서 분리되지 않은 코드입니다.

MVC / MV * 적용에 대한 나의 이해는 SoC (Separation of Concerns) 원칙을 따릅니다. 각 섹션이 별도의 문제를 해결할 수 있도록 프로그램 / 코드를 개별 섹션 / 조각으로 분리합니다 (참조 : http://en.wikipedia.org / wiki / Separation_of_concerns )

우려를 분리 할 때 많은 이점이 있습니다. 하나는 다른 것에 영향을 미치지 않으며 개발자는 나머지 등에 영향을 미치지 않고 장치에서 작업 할 수 있습니다. 등 MVC는 SoC를 따르는 유일한 패턴이 아닙니다. 기본적으로 OOP 자체는 물건을 단위로 나누는 훌륭한 개념.

MVC / MV *는 UI 관련 개발을 처리 할 때 매우 유용하지만 그 아래에는 팩토리, 싱글 톤, 파사드 등 더 많은 패턴이있을 수 있습니다. 대규모 프로젝트의 대다수는 여러 측면을 처리하는 여러 계층으로 구성되지만 UI는 필수는 아닙니다. 어떤 경우. MVC가 많이 보일 수 있습니다. 많은 프로젝트에 UI 요소가 있기 때문입니다.

따라서 MVC의 단점에 대해 이야기하는 동안 실제로 수행하는 프로젝트에 따라 다릅니다. UI가 있습니까? 뛰어난 확장 성 / 확장 성이 필요합니까? UI와 시스템 사이에 많은 상호 작용이 있습니까? 예를 들어, 간단한 정보 웹 페이지에는 나중에 대화 형 페이지로 확장하려는 경우가 아니라면 MVC가 전혀 필요하지 않습니다.

MVC (또는 더 일반적인-디자인 패턴)를 평가하려면 컨텍스트를 제공하고 복잡성, 확장 성, 테스트 가능성, 유지 관리, 시간 제약 등을 생각하십시오.