2011-05-12 6 views
1

내가 CanExecute()Execute()의 사용을 이해하지만, 나는 다음과 같은 시나리오에 대해 궁금 해요 : 기본적으로MVVM : Execute 메서드 내에서 "CanExecute"메서드를 검사해야합니까?

public class MyViewModel : NotificationObject 
{ 
    public MyViewModel() 
    { 
     FooCommand = new DelegateCommand(DoFoo, CanDoFoo); 
    } 

    public Bar MyBar { get; set; } 

    public DelegateCommand FooCommand { get; private set; } 

    public Boolean CanDoFoo() 
    { 
     return (MyBar != null) 
    } 

    public void DoFoo() 
    { 
     MyBar.BarFunc(); //Potential for a NullReferenceException 
    } 
} 

, 소멸보기는 분명히 ICommand의 포인트를 파괴합니다 (DoFoo 방법에 직접 전화를 결정할 수 인터페이스)를 호출하여 NullReferenceException을 발생시킵니다. 조금 주관적 일지 모르지만 나는 그것을하는 "표준"방법을 기대하고 있습니다.

  1. 방지 if (MyBar != null) 첫째을 수행하여 가능한 NullReferenceException이 :

    우리를합니까?
  2. CanDoFoo()이 true를 반환하는지 확인하여 가능한 NullReferenceException을 방지 하시겠습니까?
  3. 소비보기가 올바르게 작동하고 DoFoo() 방법을 호출 할 수 있다고 이미 확인했다고 가정합니다. 보조 노트, I는 단위 테스트를 작성 할 때 누군가가 자신의 CanExecute() 대응을 호출하지 않고 Execute() 메서드를 호출하여 내 뷰 모델을 깰 수 있다는 것을 깨달았 때문에이이 질문 주요 원인으로


? 분명히 단위 테스트에서 나는 이 방법을 실행하기 전에 실행하지만보기를 소비하면 무시할 수 있습니다.


업데이트 : (시나리오 2)이 질문에, 나는 또한 DoFoo() 방법은 예외의 측면에서 휴식하지 않는 시나리오에 추가 할 수 있지만, 논리적으로 깨질 수에 대한 확장으로

?

public class MyViewModel : NotificationObject 
{ 
    public MyViewModel() 
    { 
     FooCommand = new DelegateCommand(DoFoo, CanDoFoo); 
    } 

    public Int32 Age { get; set; } 

    public DelegateCommand FooCommand { get; private set; } 

    public Boolean CanDoFoo() 
    { 
     return (Age >= 21) 
    } 

    public void DoFoo() 
    { 
     ProvideAlcohal(Age); 
    } 
} 

이 두 번째 시나리오는 실제로 중단되지 않지만 (명령이 정밀하게 처리 될 수 있음) 논리적으로 중단됩니다. 그렇다면 CanDoFoo()을 호출하여 비즈니스 로직의 유효성을 다시 확인하거나 소비보기가 작동한다고 가정합니까? (이는 비즈니스 로직 만 위반한다는 것을 기억하십시오.)

기본적으로이 점은 ... 우리가 소비하는 관점이 오작동으로 발 자체를 쏘지 않도록 예방 조치를 취하고 있습니까?

답변

5

이 작업을 수행 할 것 WPF 나 실버 라이트에서 호출 명령의 모든 구현, 그래서 당신은 UI 시스템에서 그것에 대해 걱정할 필요가 없습니다 ...

는하지만 공공 방법이다. null 확인은 가장 빠른 작업 중 하나입니다. 그것은 상처를주지 않으며 당신이 guard 절없이 null 예외를 던질 것이기 때문에 훨씬 더 안전합니다.

의미 상으로는 CanExecute이 null 체크와 다르게 구현 될 수 있으므로 메서드에서 null 체크를 수행해야하며 반드시 CanExecute을 검사하지 않아도됩니다.

+0

나는 또한 null에 대한 검사가 일반적인 방어 코딩 기술이어야한다고 덧붙였다. 당신이 정말로 null에 대한 예외를 원한다면 스스로 확인하고 명시 적으로 예외를 처리하십시오. 이렇게하면 예외를보다 잘 제어 할 수 있으므로 응용 프로그램에서보다 의미있는 결과를 얻을 수 있습니다. – SRM

+0

제 질문이 조금 더 확대되었습니다. 애플리케이션 예외를 방지 할 필요성을 이해할 수 있지만, ViewModel을 비즈니스 로직을 무너 뜨리지 않는 것은 무엇입니까? –

+0

확인을 해치지 않습니다. 그러나 더 좋은 질문은 :'Execute'가 호출되었지만'CanExecute'가 false 일 때 당신이하고 싶은 것은 무엇입니까? 조용히 실패하고 싶니? 아니면이 사건을 처리하기 위해 뭔가를하고 싶습니까? 그것을 결정하는 것은 비즈니스 논리에 달려 있습니다. –

관련 문제