내가 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을 발생시킵니다. 조금 주관적 일지 모르지만 나는 그것을하는 "표준"방법을 기대하고 있습니다.
- 방지
if (MyBar != null)
첫째을 수행하여 가능한 NullReferenceException이 : 우리를합니까? CanDoFoo()
이 true를 반환하는지 확인하여 가능한 NullReferenceException을 방지 하시겠습니까?- 소비보기가 올바르게 작동하고
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()
을 호출하여 비즈니스 로직의 유효성을 다시 확인하거나 소비보기가 작동한다고 가정합니까? (이는 비즈니스 로직 만 위반한다는 것을 기억하십시오.)
기본적으로이 점은 ... 우리가 소비하는 관점이 오작동으로 발 자체를 쏘지 않도록 예방 조치를 취하고 있습니까?
나는 또한 null에 대한 검사가 일반적인 방어 코딩 기술이어야한다고 덧붙였다. 당신이 정말로 null에 대한 예외를 원한다면 스스로 확인하고 명시 적으로 예외를 처리하십시오. 이렇게하면 예외를보다 잘 제어 할 수 있으므로 응용 프로그램에서보다 의미있는 결과를 얻을 수 있습니다. – SRM
제 질문이 조금 더 확대되었습니다. 애플리케이션 예외를 방지 할 필요성을 이해할 수 있지만, ViewModel을 비즈니스 로직을 무너 뜨리지 않는 것은 무엇입니까? –
확인을 해치지 않습니다. 그러나 더 좋은 질문은 :'Execute'가 호출되었지만'CanExecute'가 false 일 때 당신이하고 싶은 것은 무엇입니까? 조용히 실패하고 싶니? 아니면이 사건을 처리하기 위해 뭔가를하고 싶습니까? 그것을 결정하는 것은 비즈니스 논리에 달려 있습니다. –