2010-07-27 4 views
10

Silverlight 커뮤니티에는 XAML의 코드 숨김 파일을 가능한 한 무료로 유지하는 데 많은 노력이 필요합니다. 이것의 진정한 동기는 무엇입니까?XAML 코드에서 코드를 배제하는 진정한 이점은 무엇입니까?

예를 들어, 이벤트 처리기 대신 명령을 사용하면 어떤 이점이 있습니까? 있는 경우

<Button x:Name="SaveButton" Content="Save" Click="SaveButton_Click" /> 

... 

private void SaveButton_Click(object sender, RoutedEventArgs e) { 
    _myViewModel.SaveChanges(); 
} 

그렇다면 왜 그렇습니까?

<Button x:Name="SaveButton" Content="Save" Command="{Binding SaveCommand}" /> 

내보기 모델의 SaveCommand 효과적으로 SaveChanges()를 호출하는 것입니다 경우 분명히.

뷰가 100 % XAML이고 뷰 모델을 XAML로 인스턴스화하고 뷰와 뷰 모델 간의 연결이 바인딩을 통해 완전히 완료되는 상황이 발생할 수 있습니다. 물론 깨끗 하긴하지만 그게 또 뭐야? 융통성 있는? 왜? 뷰는 여전히 적절한 ViewModel과 함께 작동해야하므로, 둘 사이의 연결이 존재하고 암시 적이면 더 명확하게 나타내지 않는 것이 좋습니다. 또한 컴파일 타임 지원을 잃는 단점이 있습니다. 내 버튼을 존재하지 않는 이벤트 핸들러에 연결하면 컴파일러에서 알려줍니다. 존재하지 않는 명령에 바인드하면 안됩니다.

+1

커맨드가 광범위하게 적용되는 어플리케이션이 없다면 추가 타이핑이 무엇을 구매하는지 실제로 알지 못합니다. 당신이 말했듯이, 그것은 viewmodel의 테스트 가능성에 영향을 미치지 않습니다. 일부 코드 숨김 코드가 있으면 해당 뷰 모델에 있어야하는 논리를 몰래 멈출 수 없다는 견해가 있습니다. –

+0

우선 순위는 xaml/codebehind 태그가 아닌 테스트 가능성 때문입니다. 이 질문은 코드 예제에 이러한 대안을 테스트하는 두 가지 방법이 있다면 정말 흥미로울 것입니다. 즉 ViewModel.SaveChanges()에 대한 테스트와 ICommand 기반 테스트입니다. – itchi

답변

3

단위 테스트 및/또는 TDD를 더 쉽게 만듭니다. MVVM과 명령을 사용하여 본질적으로 뷰 모델을 작성하고 TDD 스타일을 명령 할 수 있으며 실제로 XAML 뷰가 전혀 없어도 대부분의 뷰 논리를 테스트 할 수 있습니다.

+1

어떻게? 당신은 당신의 견해를 테스트하는 단위입니까? 내가 제안하는 것은 뷰 모델에 실제 영향을 미치므로 두 시나리오 모두에서 동일하게 테스트 할 수 있습니다. –

+0

@Matt : 명령 인터페이스는 이벤트 이상을 제공합니다. – AnthonyWJones

+0

내 대답 업데이트 ... XAML보기가 프레젠테이션에 대해서만되면 뷰 모델 및 명령에 있기 때문에 모든 프레젠테이션 동작을 단위 테스트 할 수 있습니다. 뷰의 시각적 정확성은 사람이 테스트합니다. –

1

아마도 많은 논거가있을 수 있지만 실용적인 이유는 입니다. ViewModel은 단위 테스트를 작성하지 않는 한 거의 제공하지 않으며, 이는 종속성 주입, IoC, blah, blah 등의 기술을 사용하여 단위 테스트를 수행 할 수있는 방식으로 ViewModel을 작성해야 함을 의미합니다. 등등.

결과적으로 UI 코드를 더욱 통합적으로 유지했다면 달성 할 수있는 것보다 더 많은 부분에서 응용 프로그램 코드를 테스트 할 수 있습니다.

필자는 필자에게 필자가 반드시 권장하는 것은 아니지만, 적절한 디자인 노력과 사전 고려 사항이 필요하다. 따라서 이러한 접근법을 구축하는 데 드는 비용은 상당히 높지만 품질 향상으로 인한 비용 절감 효과는 그만큼 클 수 있습니다.

+0

물론이 모든 것을 수행합니다. 모든 뷰 모델에 대한 전체 단위 테스트가 있습니다. 나는 근본적인 무언가를 놓치고있는 것처럼 느낀다. 뷰가 뷰 모델로 다시 호출하는 방식은 테스트에서별로 차이가없는 것처럼 보입니다. 이 접근법의 장점 중 하나는 IoC를 사용하여 더미 데이터를 삽입하고 실제 사용에 더 가까운 방식으로 블렌드에서 뷰를 디자인 할 수 있다는 점입니다. –

+0

매트 당신은 아무것도 놓치지 않았습니다. 이벤트 처리기 vs Command를 사용하면 테스트 가능성에 영향을주지 않습니다. 모두가 MVVM 악 대차에 뛰어 들었고 종종 많은 시나리오에서 이점이없는 경우에도 항상 명령을 사용합니다. – Schneider

1

내가 명령과 함께 표시하는 주요 이점은 동작을 실행할 수있는 (즉, 컨텍스트) 의 유효성을 확인하는 두 가지 요구 사항이있는 경우입니다. 즉, 단순히 클릭을 곧은 메서드 호출로 연결하는 것이라면 동의합니다. 이점도 없습니다. 그러나 클릭이 컨디셔닝되어야하고 컨텍스트에 따라 버튼이 비활성화 된 경우 바인딩은 CanExecute 속성을 통해이 작업을 용이하게합니다.

이렇게하면보기의 컨트롤에 대해 걱정할 필요없이 ("이 컨트롤을 찾아서 지금 실행할 수 없기 때문에이 컨트롤을 사용할 수 없도록 설정하는 로직이 있습니다) 대신 명령을 생성하고 단순히이 뷰의 검증 독립적이다. 거짓 반환을 실행할 수 있도록 당신이 그것을 결합 할되면, 자체 바인딩 컨트롤의 enabled 속성을 관리 할을 담당한다. 많은 노력이 실버 라이트가

5

커뮤니티에서 XAML의 코드를 코드 뒤에 무료로 코드 과 같이 유지할 수 있습니다. 의 진정한 동기는 무엇입니까?

나는 가능한 한 코드가 무료 인 코드를 원한다는 사람들은 실제로 요점을 얻지 않고 MVVM 악 대차에 뛰어든 사람이라고 말합니다. (또는 당신이 그들의 요지를 잘못 해석했는지).

요점은 코드 숨김을 코드에서 없애고 뷰가 시각적 인 표시에만 책임이 있음을 확인하는 것입니다. 많은 시각적 측면을 선언적으로 정의 할 수 있다는 사실은 코드 숨김에 코드가 적다는 것을 의미하지만 필요하다고 생각되는 코드 숨김을 주저해서는 안되며 뷰의 책임 범위를 벗어나지 않습니다.

이벤트 처리기 대신 명령을 사용하면 어떤 이점이 있습니까?

명령은 이벤트 처리기에없는 두 가지 기능을 제공합니다. 일부 WPF 컨트롤은 명령의 CanExecute 속성을 인식하므로 명령을 실행할 수 없으면 버튼을 비활성화 할 수 있습니다. 또한 디자이너와 바인딩 프레임 워크는 명령을 인식합니다.

당신은 단지 명령을 사용하는 대신 그냥 이벤트 핸들러에서 메소드를 호출에는 큰 장점은 이없는 버튼을 눌러의 메소드를 호출 할합니다. 따라서이 방법을 사용하는 것을 두려워하지 마십시오. (프로그래머보다 디자이너를 선호하는 세 번째 접근법은 Blend 4의 CallMethodAction을 사용하는 것입니다.)

+0

일반적으로 동의하지만, xaml에 코드가 없어도 분리를 유지하는 것이 중요하다고 생각합니다 가능한 깨끗한.때로는 규칙이 깨지는 경우가 있지만 반복해서 반복 할 경우 불필요하게 규칙을 위반하는 습관을 가지기 쉽습니다. – kyoryu

+0

"XAML"에 코드가 없으면 SoC와 아무런 관련이 없습니다 ("깨끗한 분리"라는 의미). 코드가 뷰의 책임과 관련된 경우 SoC 원칙을 위반하지 않습니다. – Schneider

관련 문제