Z tego, co przeczytałem, projekty CQRS obejmują asynchroniczne polecenia, w których polecenia są umieszczane w kolejce. Użytkownik zakłada, że wszystko jest w porządku, a ankiety UI lub za pośrednictwem timera otrzymają sygnał zwrotny, jeśli wszystkie zadziałają lub nie.Czy polecenia muszą być asynchroniczne w CQRS?
Jak by to działało, gdybym miał interfejs użytkownika, do którego przeciągam foldery w drzewie? Mógłbym mieć jednego użytkownika usuwając folder, podczas gdy inny przeciągał do niego folder (aby zrobić z niego podfolder).
Tak więc od interfejsu użytkownika mogłem pokazać, że przeciągnięcie zostało wykonane, a następnie w pewnym czasie sprawdzić, czy mój model odczytu został zaktualizowany (tzn. Sprawdzić folder nadrzędny przeciągniętego folderu i czy jest ustawiony prawidłowo wiem, że zadziałało).
Jeśli użytkownik wykonał pewną liczbę operacji przeciągania, musiałbym zachować listę tych operacji w interfejsie użytkownika i sprawdzić magazyn odczytu (usuwając wszelkie udane polecenia z listy).
Może są lepsze sposoby na zrobienie tego.
To po prostu wydaje się dużo pracy w interfejsie użytkownika i bardziej podatne na błąd, podczas gdy jeśli po prostu uruchomić polecenie synchroniczne i jeśli wszystko jest w porządku, to przejdę do następnej operacji.
Dzięki za odpowiedź. –
Widzę to bardziej jako dążenie do informowania użytkowników jak najszybciej, czy ich działania się powiedzie, czy nie. Moim zdaniem, z punktu widzenia użyteczności UI jest to złe, aby pozwolić użytkownikom swobodnie przeciągać foldery tylko po to, aby "wywołać serwer" kilka sekund później i dowiedzieć się, że wszystkie te działania zostały odrzucone - myślę, że użytkownik powinien być poinformowany od razu. Ten sam przypadek dotyczy problemów z zapisywaniem danych (sprawdź poprawność!) I większość, jeśli nie wszystkie inne warunki błędu. – Dav
"Dążenie do informowania użytkowników jak najszybciej, czy ich działania się powiedzieją" nie jest uniwersalnym wymogiem, który musi spełnić każdy system. Jeśli aktualny stan aplikacji ma kluczowe znaczenie dla określenia działań dostępnych dla użytkownika, to polecenia asynchroniczne prawdopodobnie nie są najlepszą decyzją projektową, ale to nie znaczy, że używanie poleceń synchronicznych to jakaś magiczna kula, która nie pozwoli na zmianę stanu * pomiędzy poleceniami wydanymi przez jednego użytkownika *. – arootbeer