MVVM - 무엇이 무엇을 포함해야하는지 ... 무엇을 만들어야합니까?

Question

MVVM 패턴을 사용하여 모든 것이 어떻게 맞는지에 대해 머리를 써야합니다. 그것은 모두 실제로 아주 간단하게 보이지만 그것을 구현하려고하면 내가 코딩하려고 시도하는 여러 가지 다른 규칙을 위반하는 것 같습니다.

사이드 노트와 마찬가지로 Silverlight 또는 WPF가 아닌 Flex를 사용하여 패턴을 구현하려고합니다. 그렇다면 왜 이런 일을해서는 안되는 지에 대한 좋은 이유가 있다면 그걸 듣고 싶습니다. .

나는 여러 가지 견해가있는 곳에 문제가 있습니다. 때로는 페이지에 두 개의보기를 동시에 표시해야합니다. 때로는 다시 단일보기로 전환합니다. 내 일반적인 플렉스 뇌에서 나는 모든 다른 뷰 (코드 숨김과 동등하게)를 포함하는 코드 숨김이있는 메인 뷰를 가질 것이다. 그런 다음 기본보기는 다른 개별보기를 전환합니다.

MVVM에서 구현하려고하면 ViewModels에서 내 Views을 디커플링하는 바인딩을 사용하여 MVVM의 원칙을 고수하려고합니다. 응용 프로그램 전체 상태에 대해 ViewModel을 만들고 해당 데이터에 내 ApplicationView을 바인딩하고 모든 하위보기를 전환한다고 가정 해 보겠습니다.

이제 내 하위 뷰에 대한 내 뷰 모델을 어디에 만들어야합니까? 나는 ApplicationView 안에 시도해 보았습니다. 그리고 나서 나는 애플리케이션 뷰 밖에서 시도해 보았고 ApplicationView에 인스턴스를 전달한 다음 하위 모델에 바인드했습니다. 내가 놓친 게 있니? 이 방법들 중 어느 것도 이것의 분리를 시도하는 요점에 맞지 않는 것 같습니다.

좋은 책이나이 문제를 설명하는 링크는 많은 도움이 될 것입니다.

건배, 제임스

Answer 1

당신이 말하는 접근법은 ViewModel 구성입니다. 자신의 ViewModel 엔터티에 바인딩해야하는 여러 개의 복잡한보기 파트가있는 곳입니다. 이 접근 방식은 각 하위 ViewModel에 대한 속성을 사용하여 루트 ViewModel을 생성해야합니다. 그런 다음 루트보기가 루트보기 모델에 바인딩되고 각보기 (표시되거나 축소되었는지 여부)는 루트 ViewModel의 해당 속성에 바인딩됩니다.

뷰 모델은 다음과 같이 보일 것이다 :

public class RootViewModel 
{ 
    ChildViewModelA ChildA { get; set; } 
    ChildViewModelB ChildB { get; set; } 
} 

보기는 다음과 같이 보일 것이다 :

<Grid> 
    <ChildViewA DataContext="{Binding ChildA}" /> 
    <ChildViewB DataContext="{Binding ChildB}" /> 
</Grid> 

당신은 또한 자신이 활성 작업 공간을 선택할 수 있도록 멀리에서이를 구현할 수 있습니다.

뷰 모델은 다음과 같을 것이다 : 이것은 적당한 시각적 표현 될 것이다

<Grid> 
    <Grid.Resources> 
     <DataTemplate DataType="ChildViewModelA"> 
      <ChildViewA /> 
     </DataTemplate> 
     <DataTemplate DataType="ChildViewModelB"> 
      <ChildViewB /> 
     </DataTemplate> 
    </Grid.Resources> 
    <ContentControl Content="{Binding ActiveWorkspace}" /> 
</Grid> 

실제 유형에 기초 implicity 선택되고 :

가

public class RootViewModel 
{ 
    public List<ViewModel> ChildWorkspaces { get; set; } 
    public ViewModel ActiveWorkspace { get; set; } 

    public RootViewModel() 
    { 
     ChildWorkspaces.Add(ChildViewModelA); 
     ChildWorkspaces.Add(ChildViewModelB); 
    } 
} 

뷰 같을 것이다 ActiveWorkspace에 저장된 객체.

내 대답은 WPF입니다.

"ViewModel"의 복수가 모호 할 수 있음을 알 수 있듯이, 나는 그 모든 구문에 얽매이지 않도록 노력했다. 때때로 ViewModel을 적절히 구조화하기 위해 여러 하위 엔터티를 구성해야 할 필요성을 느낍니다. 그러나 모든 ViewModel 엔티티는 루트보기 모델 객체의 어딘가에있을 것입니다.

WPVM에서 MVVM을 구현할 때, 나는이 응답의 후반부에 설명 된 것처럼 데이터 컨텍스트를 암시 적으로 적용 할 시각적 요소를 추론하는 것을 선호합니다. 더 복잡한 시나리오에서는 DataTemplateSelector를 사용하여 의사 결정을 수행하는 것을 선호합니다. 그러나 매우 간단한 경우에는 C#/ActionScript에서 필수적으로 또는 바인딩을 통해 선언적으로 DataContext를 명시 적으로 적용 할 수 있습니다.

희망이 도움이됩니다.

Answer 2

나는 몇 가지 다른 플렉스 프로젝트에 사용되는 MVVM 접근 방식의 변형을 본 적이 있지만 난 지금 나에게 완벽하게 느낀다 접근을 보지 못했다. 즉, 프리젠 테이션 모델을 사용하면 Flex에서 테스트하는 것이 훨씬 쉬워 졌으므로이 패턴을 중심으로 더 많은 응용 프로그램이 개발되기 시작할 것입니다.

Flex에서 MVVM을 구현하는 가장 쉬운 방법은 ViewModel 개를 응용 프로그램 내에 배치하는 것입니다. Model/ModelLoactor. ModelLoactor에는 모든 글로벌 데이터가 들어 있으며 ViewModels의 접근 자로도 사용됩니다. ApplicationViews은 ModelLocator을 통해 해당 ViewModel에 바인딩 할 수 있으며 ViewModels은 명령과 부모를 통한 바인딩을 통해 업데이트 할 수 있습니다. ModelLocator. 이 접근법의 한 가지 이점은 모든 데이터 로직이 지역화되어 있다는 것입니다. 물론 이것은 또한 단점으로 볼 수 있습니다. ModelLocator은 모두 ViewModels에 대한 하드 코딩 된 참조로 인해 취성이 있습니다.

메이트 프레임 워크를 사용하면 더 깔끔한 접근 방식을 사용할 수 있습니다. 메이트는 적절한 ApplicationViews에 ViewModels을 훨씬 더 분산 주입 할 수 있습니다. (Swiz로이 작업을 수행 할 수 있다고 가정합니다. 그 프레임 워크에 친숙하지 않습니다.) Mate의 경우 각 ApplicationView에는 ViewModel이 맵을 통해 주입됩니다. 이 접근법은 멋진데 ViewModels은 EventMap (FrontController의 메이트 버전)을 사용하여 업데이트 할 수 있습니다. 본질적으로 ApplicationViews은 하나 이상의 EventMaps에 의해 처리되는 이벤트를 보내고 이러한지도는 ViewModels 중 하나 이상을 변경할 수 있습니다.이 접근법은 하나의 사용자 동작 또는 이벤트가 ApplicationView에서 한 번에 여러 ViewModels의 상태를 변경할 수있게합니다. 또한이 로직이 Mate의 EventMaps으로 추출되기 때문에 이벤트 처리 방법이나 변경된 ViewModels이 매우 쉽게 변경됩니다. 물론이 접근법의 주요 단점은 Mate를 프레임 워크로 사용하는 것이지 프로젝트의 요구 사항에 따라 옵션이 될 수 없다는 것입니다.

도움이 되었기를 바랍니다.

Answer 3

나는 MVVM (Silverlight) 대 PresentionModel (Flex)의 비교를 공유하고 싶었습니다. 그것은 같은 패턴의 두 가지 구현이/다른 방법을 보여줍니다 비교 :

http://houseofbilz.com/archives/2010/12/29/cross-training-in-silverlight-flexmvvm-vs-presentation-model/