문제

저는 현재 작업 중인 새 애플리케이션(PRISM 2/WPF 앱)에 가장 잘 접근하는 방법에 대한 아이디어를 찾기 위해 PRISM 2 샘플을 살펴보았습니다.특히 PRISM과 함께 제공되는 뷰 주입 샘플 애플리케이션을 살펴보면 모든 뷰가 프리젠터(또는 ViewModel)가 뷰와 상호 작용할 수 있도록 하는 인터페이스를 구현한다는 것을 알 수 있습니다.

과거에는 이 작업을 반대 방향으로 수행했습니다. 뷰가 다음과 같이 프리젠터의 메서드를 직접 호출할 수 있도록 뷰에 프리젠터를 삽입했습니다.

    public partial class SomeView : ModuleBase
    {

        private ISomePresenter _somePresenter;

        public SomeView (ISomePresenter somePresenter):this()
        {
            // Give the view a reference to the presenter
            _somePresenter = somePresenter;
            // Bind the View to the presenter
            DataContext = _somePresenter;
        }

    private void btnSubmit_Click(object sender, RoutedEventArgs e)
    {
        // The view can call actions directly on the presenter (OK I should probably use a command for this)
        _somePresenter.SomeAction();
    }
}

위의 기술은 나에게 충분히 합리적으로 보였지만 샘플을 보면 접근 방식에 의문이 들기 시작했습니다.이 문제를 해결하는 가장 좋은 방법에 대한 견해를 갖고 있는 사람이 있습니까?

  • 프리젠터를 뷰에 추가하고 뷰가 프리젠터와 상호 작용하도록 합니다.
  • 프리젠터에 뷰를 추가하고 프리젠터가 뷰와 상호 작용하도록 합니다.
  • 내가 아직 생각하지 못한 완전히 다른 것이 있습니까?
도움이 되었습니까?

해결책

나는 그것이 모두 맛의 문제라고 생각합니다.개인적으로 나는 당신이 보고 있는 샘플에서 그것을 보는 방식을 좋아합니다.IView에는 SetViewModel(...)이라는 하나의 메서드가 있습니다.IViewModel에는 기본적으로 DI 인스턴스화된 IView를 반환하는 Object 유형의 View라는 속성이 있습니다.

내가 이 방식을 좋아하는 이유는 거의 항상 ViewModel을 먼저 만들고 싶기 때문입니다. 아무도 인스턴스에 대한 참조를 얻는 것(뷰 삽입 또는 ContentControl과 같은 뷰 바인딩)을 제외하고 내 IView로 무엇이든 할 수 있도록 코드에 포함시켰습니다. 이것이 바로 객체 유형인 이유입니다.코드가 뷰와 통신해야 하는 경우 항상 VM을 통해 이루어지며, 심지어 뷰는 일반적으로 바인딩을 통해 업데이트됩니다.VM->UpdateBinding->View보다 View->ViewModel->UpdateBinding->View에서 이동하는 것이 이상하게 느껴질 것입니다.

질문에 대답하려면 일반적으로 코드 숨김의 발표자에 대한 참조가 필요하지 않습니다.일반적으로 VM에 바인딩되는 뷰의 명령을 사용하여 이를 처리할 수 있습니다.어떤 경우에는 예제에 있는 작업을 수행하기 위해 발표자를 계속 참조하고 싶을 수도 있지만 올바른 도구 세트가 있으면 피할 수 있습니다(SL에 내장된 명령이 없기 때문에 SL이 더 어려워집니다).

말했듯이, 모든 것은 취향의 문제입니다...

-제르

다른 팁

ViewModel을 MVVM의보기에 매핑하는 가장 일반적인 접근법은 DataTemplate :

<DataTemplate DataType="{x:Type vm:SomeViewModel}">
    <v:SomeView />
</DataTemplate>

ContentControl 또는 ItemsControl에 ViewModel 인스턴스를 표시하면 WPF DataContext ViewModel 인스턴스에.

그렇게하면 뷰 모델의보기에 대한 참조가 없으며보기는 DataContext 재산. View의 코드-비만에서 ViewModel에 실제로 액세스 해야하는 경우 언제든지 캐스팅 할 수 있습니다. DataContext (그러나 이것은 뷰가 뷰 모델의 실제 유형에 대해 알고 있음을 의미하며, 이는 커플 링을 유도합니다).

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top