Выполняя иначе простой метод «thunk», async создает в памяти состояние async state machine, а не async - нет. Хотя это часто может указывать на использование версии non-async, поскольку она более эффективна (это правда), это также означает, что в случае зависания у вас нет доказательств того, что этот метод задействован в «стеке возврата / продолжения», что иногда затрудняет понимание повесы.
Итак, да, когда perf не критичен (и обычно это не так), я брошу async на все эти методы thunk, чтобы у меня была машина состояния async, чтобы помочь мне диагностировать зависания позже, и также, чтобы гарантировать, что, если эти методы thunk когда-либо будут развиваться со временем, они обязательно вернут сбитые задачи вместо throw.
Наиболее простым решением было бы придерживаться шаблона MVVM, создав коллекцию и наполнив ее данными из другого класса, как вы уже упоминали. Это легко, и все знают, что происходит. Кроме того, таким образом, контекст данных остается в той же модели представления и - если вы что-то меняете - он также остается в этом контексте. В вашем случае это означает, что вы должны создать ObservableCollection<Student> Students
и заполнить его содержимое в MainViewModel
.
Если к этим данным нужно обращаться со всего приложения, вам следует подумать о реализации DataManager (например, синглтоном), а не о копировании данных в каждой модели представления.
Найдено решение:
MainViewModel
public class MainViewModel : ViewModelBase
{
public StudentViewModel StudentViewModel { get; set; }
public MainViewModel()
{
StudentViewModel = new StudentViewModel();
}
}
MainView
<ComboBox
DataContext="{Binding StudentViewModel}"
ItemsSource="{Binding Path=Students, UpdateSourceTrigger=PropertyChanged}"
/>
StudentViewModel [ 119]
private ObservableCollection<Student> _students;
public ObservableCollection<Student> Students
{
get => _students;
set
{
if (_students == value) return;
_students = value;
RaisePropertyChanged("Students");
}
}