Ich denke, mit dem Konzept wirst Du recht schnell noch sehr viel größere Probleme haben
WPF möchte nämlich nicht aus keinem anderen Thread genutzt werden, als dem, in dem es läuft.
Die einfachste Lösung wäre, wenn Du eine async-Methode schreibst:
C#-Quelltext
1: 2: 3: 4:
| private async Task<DataObject> LoadDataAsync(string filter = "") { } |
und musst dann über Dispatcher.Invoke die Property setzen:
C#-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:
| private async void RefreshData() { var viewModel = DataContext as MyViewModel;
await viewModel.LoadDataAsync("1234") .ContinueWith(task => { if (Dispatcher.CheckAccess()) viewModel.Data = task.Result; else Dispatcher.Invoke(() => DataContext = task.Result); }); } |
Das hat aber den Nachteil, dass die RefreshData-Methode im CodeBehind liegen muss oder Du im ViewModel den Dispatcher brauchst.
Beides ist streng betrachtet eher dirty MVVM.
Der Alternativ-Vorschlag passt besser zu MVVM: Die IsAsync-Property vom Binding
Die einfach auf true setzen und die Property wird asynchron abgefragt.
Du könntest in deinem ViewModel dann z.B. eine Filter-Property setzen. Diese Filter-Property setzt intern aber auch die Data-Property auf null.
WPF merkt also, dass die Data-Property neu abgefragt werden muss und startet einen Thread, in dem das getan wird.
In der Data-Property prüfst Du dann, ob das Objekt null ist. Ist es null, dann fragst Du die Daten mit Hilfe des Filters synchron ab, aktualisierst das backing-field und gibst es zurück.
Ist doof, dass die Property dann synchron Daten abfragt, da das eben auch der Fall ist, wenn man die Property nutzt. Allerdings ist dafür das Management im Bezug auf die View bedeutend einfacher.
Wenn die abagerufenen Daten aber zwischengespeichert werden, muss nur einmal abgerufen werden.
Alternativ kannst Du ja auch immer noch eine async-Methode verwenden, die nur die Property asynchron abfragt.
Das wären die zwei einfachsten Möglichkeiten, die mir jetzt so spontan einfallen