С точки зрения дизайна модель представления тесно связана с проблемами пользовательского интерфейса при вызове DisplayAlert
.
Эти проблемы следует абстрагировать, чтобы обеспечить большую гибкость, тестируемость и ремонтопригодность.
Воспользуйтесь преимуществами принципов инверсии зависимостей
Например, создайте абстракцию для представления желаемой функциональности
public interface IDialogService {
Task<bool> DisplayAlert (String title, String message, String accept, String cancel);
//...other members
}
Его реализация в основном обернет реальные проблемы пользовательского интерфейса
public class DialogService : IDialogService {
public Task<bool> DisplayAlert (String title, String message, String accept, String cancel) {
return App.Current.MainPage.DisplayAlert(title,message, accept, cancel);
}
//...other members
}
Модель представления будет явно зависеть от абстракции службы.
Также старайтесь избегать async void
за исключением обработчиков событий
public class LoginPageViewModel : ViewModelBase {
private readonly IDialogService dialog;
public LoginPageViewModel(IDialogService dialog) {
LogoutCommand = new RelayCommand(LogoutExecution);
}
public ICommand LogoutCommand { get; private set; }
void LogoutExecution() {
logOut += onLogOut;
logOut(this, EventArgs.Empty);
}
private event EventHdnalder logOut = delegate { };
private async void onLogOut(object sender, EventArgs args) {
logOut -= onLogOut;
var result = await dialog.DisplayAlert("Alert!","Are you sure you want to logout?", "Yes", "No");
if (result) {
//Code Execution
await LogOut();
}
}
//...
}
Предполагая, что не было других тесно связанных зависимостей,тогда LoginPageViewModel
должен быть в состоянии быть изолированным без какого-либо влияния на эффекты, связанные с интерфейсом пользователя.При условии правильно смоделированных зависимостей внедряются в испытуемый субъект.
В производстве система может быть настроена на использование служб зависимостей для внедрения реализаций служб в зависимые классы.