[model-view-controller] MVC와 MVVM의 차이점은 무엇입니까? [닫은]

MVC는 통제 된 환경이고 MVVM은 반응적인 환경입니다.

통제 된 환경에서는 코드가 적고 일반적인 논리 소스가 있어야합니다. 항상 컨트롤러 내에 있어야합니다. 하나; 웹 세계에서 MVC는 뷰 생성 로직과 뷰 동적 로직으로 쉽게 구분됩니다. 생성은 서버에서 이루어지고 동적 수명은 클라이언트에서 이루어집니다. AngularJS와 결합 된 ASP.NET MVC의 경우이 점을 많이 볼 수 있지만 서버는 모델을 작성하고 모델에 전달하여 클라이언트로 보냅니다. 그러면 클라이언트는 View와 상호 작용하며이 경우 AngularJS는 로컬 컨트롤러로 들어갑니다. 제출 된 모델 또는 새 모델은 서버 컨트롤러로 다시 전달되어 처리됩니다. (사이클이 계속되고 소켓이나 AJAX 등으로 작업 할 때이 처리에 대한 다른 많은 번역이 있지만 모든 아키텍처에서 동일합니다.)

MVVM은 일반적으로 일부 이벤트를 기반으로 활성화되는 코드 (예 : 트리거)를 작성하는 사후 환경입니다. MVVM이 번성하는 XAML에서는 내장 된 데이터 바인딩 프레임 워크를 사용하여이 작업을 쉽게 수행 할 수 있지만 BUT은 프로그래밍 언어가있는 모든 뷰에서 모든 시스템에서 작동합니다. MS 특정이 아닙니다. ViewModel (일반적으로 속성 변경 이벤트)이 실행되고 View는 생성 한 트리거에 따라 반응합니다. 이것은 기술적으로 얻을 수 있지만 결론은 View가 Stateless이며 논리가 없다는 것입니다. 단순히 값을 기준으로 상태를 변경합니다. 또한 ViewModel은 로직이 거의없는 상태 비 저장이며 모델은 상태 만 유지해야하므로 기본적으로 로직이 0 인 상태입니다. 나는 이것을 응용 프로그램 상태 (모델), 상태 번역기 (ViewModel), 그리고 시각적 상태 / 상호 작용 (보기)으로 설명합니다.

MVC 데스크톱 또는 클라이언트 측 응용 프로그램에는 모델이 있어야하며 컨트롤러에서 모델을 사용해야합니다. 모델을 기반으로 컨트롤러가보기를 수정합니다. 보기는 일반적으로 인터페이스가있는 컨트롤러에 연결되므로 컨트롤러가 다양한보기로 작업 할 수 있습니다. ASP.NET에서 MVC의 로직은 컨트롤러가 모델을 관리하고 모델을 선택된 뷰로 전달함에 따라 서버에서 약간 뒤로 향합니다. 그런 다음 View는 모델을 기반으로하는 데이터로 채워지며 자체 로직 (일반적으로 AngularJS와 같은 다른 MVC 세트)을 갖습니다. 사람들은 이것을 논쟁하고 응용 프로그램 MVC와 혼동하여 프로젝트 유지 관리가 결국 재앙이 될 시점에서 두 가지를 모두 시도합니다. MVC를 사용할 때는 항상 논리와 제어를 한 위치에 두십시오. 컨트롤러 또는 모델 데이터를 수용하기 위해 View의 코드 뒤에 (또는 웹을 위해 JS를 통한 View에서) View 로직을 작성하지 마십시오. 컨트롤러가보기를 변경하도록합니다. View에 있어야하는 유일한 논리는 사용중인 인터페이스를 통해 작성하고 실행하는 데 필요한 모든 것입니다. 이에 대한 예는 사용자 이름과 비밀번호를 제출하는 것입니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다. 데스크톱 또는 웹 페이지 (클라이언트의) 여부에 상관없이 Controller는 View가 제출 조치를 실행할 때마다 제출 프로세스를 처리해야합니다. 올바르게 수행하면 항상 MVC 웹 또는 로컬 앱을 쉽게 찾을 수 있습니다.

MVVM은 완전히 반응하므로 개인적으로 가장 좋아합니다. 모델이 상태를 변경하면 ViewModel이 해당 상태를 수신하고 변환합니다. 그런 다음 View는 상태 변경을 위해 ViewModel을 수신하고 ViewModel의 변환에 따라 업데이트됩니다. 어떤 사람들은 그것을 순수한 MVVM이라고 부르지 만 실제로는 하나 뿐이며 어떻게 주장하는지 상관하지 않으며 항상 View에 논리가없는 순수한 MVVM입니다.

다음은 약간의 예입니다. 버튼을 누를 때 메뉴 슬라이드가 표시되도록하겠습니다. MVC에서는 인터페이스에 MenuPressed 액션이 있습니다. 컨트롤러는 메뉴 버튼을 클릭 한 후 SlideMenuIn과 같은 다른 인터페이스 방법에 따라 메뉴에서 슬라이드를 보도록 지시합니다. 어떤 이유로 왕복 여행? 컨트롤러가 당신이 할 수 없거나 다른 것을하고 싶을 경우를 대비하십시오. 컨트롤러는 별도의 지시가없는 한 뷰가없는 상태에서 뷰를 담당해야합니다. 하나; MVVM에서 애니메이션의 슬라이드 메뉴는 내장되어 있고 일반적이어야하며, 슬라이드 인하라는 메시지 대신 어떤 값을 기준으로합니다. 따라서 ViewModel을 수신하고 ViewModel에 IsMenuActive = true (또는 그에 대한) 애니메이션이 표시됩니다. 지금, 그것으로 나는 또 다른 요점을 정말로 명확하게하고 싶다고 말하면서주의를 기울여야한다. IsMenuActive는 아마도 BAD MVVM 또는 ViewModel 디자인 일 것입니다. ViewModel을 설계 할 때 View에 기능이 전혀 없다고 가정하고 변환 된 모델 상태 만 전달하면 안됩니다. 그렇게하면 메뉴를 제거하기 위해보기를 변경하고 데이터 / 옵션을 다른 방법으로 표시하기로하면 ViewModel은 신경 쓰지 않습니다. 메뉴를 어떻게 관리하겠습니까? 데이터가 의미가있을 때 그렇게됩니다. 따라서이를 수행하는 한 가지 방법은 메뉴에 옵션 목록 (아마도 내부 ViewModel 배열)을 제공하는 것입니다. 해당 목록에 데이터가있는 경우 메뉴는 트리거를 통해 열리는 것을 알고 그렇지 않은 경우 트리거를 통해 숨기는 것을 알고 있습니다. 메뉴에 대한 데이터가 있거나 ViewModel에 없습니다. ViewModel에서 해당 데이터를 표시 / 숨기기로 결정하지 마십시오. 단순히 모델의 상태를 번역하십시오. 이러한 방식으로 View는 완전히 반응적이고 일반적이며 다양한 상황에서 사용할 수 있습니다.

각각의 아키텍처에 대해 조금이라도 익숙하지 않고 인터넷에서 많은 BAD 정보를 찾을 때 매우 혼란 스러울 수 있다는 것을 배우면이 모든 것이 아마도 의미가 없습니다.

그러니 .. 이걸 얻기 위해 명심해야 할 것들. 애플리케이션 설계 방법과 STICK TO IT를 먼저 결정하십시오.

훌륭한 MVC를 수행하는 경우 Controller가 관리 가능하고 View를 완전히 제어 할 수 있는지 확인하십시오. 큰보기가있는 경우 다른 컨트롤러가있는보기에 컨트롤을 추가하는 것이 좋습니다. 다만 해당 컨트롤러를 다른 컨트롤러에 캐스케이드 연결하지 마십시오. 유지하기가 매우 실망합니다. 별도의 구성 요소로 작동하는 방식으로 잠시 시간을내어 물건을 개별적으로 설계하십시오. 그리고 항상 컨트롤러가 모델에 스토리지를 커밋하거나 유지하도록 지시하십시오. MVC에 대한 이상적인 종속성 설정은 View ← Controller → Model 또는 ASP.NET을 사용하는 것입니다 (시작하지 마십시오) Model ← View ↔ Controller → Model (여기서 Model은 컨트롤러마다 다르거 나 완전히 다른 모델 일 수 있습니다)…이 시점에서 View의 Controller에 대해 알아야 할 유일한 점은 주로 엔드 포인트 참조가 모델을 다시 전달할 위치를 아는 것입니다.

당신이 MVVM을한다면, 나는 당신의 친절한 영혼을 축복하지만, 그것을 올바르게하기 위해 시간이 걸립니다! 인터페이스를 사용하지 마십시오. View가 값을 기반으로 표시되는 방식을 결정하도록합니다. Mock 데이터가있는 View로 재생하십시오. 당시에 원하지 않더라도 메뉴를 보여주는보기가 표시되면 (예 : GOOD). 당신은보기가 정상적으로 작동하고 값을 기준으로 반응하고 있습니다. ViewModel이 특정 변환 상태에 있거나이 상태를 비우도록 ViewModel에 명령 할 때 발생하지 않도록 트리거에 몇 가지 요구 사항을 추가하십시오. ViewModel에서 View가 볼지 여부를 결정하는 것처럼 내부 논리로 이것을 제거하지 마십시오. ViewModel에 메뉴가 있거나 없다고 가정 할 수는 없습니다. 그리고 마지막으로, 모델을 사용하면 상점 상태를 변경하고 가능하게 할 수 있습니다. 여기에서 유효성 검사와 모든 작업이 수행됩니다. 예를 들어, 모델이 상태를 수정할 수없는 경우 단순히 더럽거나 무언가로 플래그가 지정됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. t 상태를 수정하면 단순히 더럽거나 무언가로 표시됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. t 상태를 수정하면 단순히 더럽거나 무언가로 표시됩니다. ViewModel이 이것을 인식하면 더러워진 것을 번역하고 View는 이것을 인식하고 다른 트리거를 통해 정보를 보여줍니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다. View의 모든 데이터는 ViewModel에 바인딩 될 수 있으므로 모든 것이 동적 일 수 있으며 ViewModel은 View가 바인딩에 어떻게 반응하는지 전혀 모릅니다. 사실 Model은 ViewModel에 대해 전혀 모릅니다. 의존성을 설정할 때 그렇게 가리켜 야합니다.View → ViewModel → Model (여기서 참고 사항 … 이것은 아마도 논쟁의 여지가 있지만 아마도 신경 쓰지 않습니다 … MODEL을 변경할 수없는 경우가 아니라면 VIEW에 모델을 전달하지 마십시오. 적절한 ViewModel. View에는 모델 기간이 표시되지 않아야합니다. 쥐가 당신이 본 데모 나 수행 방식을 깨뜨 렸습니다.

마지막 팁은 다음과 같습니다. 잘 디자인되었지만 매우 간단한 MVC 응용 프로그램을 살펴보고 MVVM 응용 프로그램에 대해서도 동일하게 수행하십시오. 하나는 유연성이 0으로 제한되어 있고, 다른 하나는 제어가없고 무제한의 유연성이 있습니다.

제어 된 환경은 일련의 컨트롤러 또는 (단일 소스)에서 전체 애플리케이션을 관리하는 데 유용하지만, 반응성 환경은 나머지 애플리케이션이 무엇을하는지 전혀 몰라도 별도의 리포지토리로 나눌 수 있습니다. 마이크로 관리 대 무료 관리.

내가 당신을 충분히 혼동하지 않았다면 저에게 연락을 시도하십시오 … 나는 그림과 예를 가지고 이것을 자세히 자세히 설명하지 않습니다.

하루가 끝나면 우리는 모든 프로그래머이며 코딩 할 때 그 무정부 상태가 우리 안에 살고 있습니다. 그래서 규칙이 깨지고 이론이 바뀌고이 모든 것이 호그 워시로 끝날 것입니다. 프로젝트와 대규모 팀에서 실제로 디자인 패턴에 동의하고이를 시행하는 데 도움이됩니다. 언젠가는 처음에 취해진 작은 추가 단계가 나중에 도약과 저축의 경계가 될 것입니다.