Question: In CompuMaster.TaskManagement könnte man evtl. - falls dort überhaupt sinnvoll - diese Funktionalität nachrüsten. Die Frage ist: macht es überhaupt dort Sinn?
Ja, das kann in CompuMaster.TaskManagement sinnvoll sein – aber nicht zwingend. Es hängt davon ab, welches Progress-Szenario Sie dort abdecken möchten.
Aus Ihrem README ist klar: Die Library modelliert bereits TaskBundles → TaskItems → TaskSteps, inkl. Rollback/Fail-Strategien, geschätzter Dauer, Abbruch und optionaler WinForms-UI. ([GitHub]1)
Damit haben Sie schon eine “Progress-Struktur” (Step-Start/Step-Ende, Status, Timing). System.Progress<T> wäre also kein Muss, sondern eher ein Adapter/Komfort-Feature.
Wann Progress<T> dort wirklich Sinn macht
1) „Sub-Progress innerhalb eines einzelnen Steps“
Aktuell ist ein Step „atomar“ gedacht (“A task step is an atomic step…”). ([GitHub]1)
Wenn Sie aber Steps haben wie „Datei kopieren“, „DB-Migration“, „Download“, dann will man innerhalb eines Steps z. B. 0–100% melden (und nicht nur „Step läuft / Step fertig“).
→ Hier ist IProgress<T> Gold wert, weil der Step-Implementierer progress melden kann, ohne die UI zu kennen.
2) UI-/Host-agnostische Progress-Ausgabe
Sie haben WinForms-UI im Repo, aber die Core-Library ist auch ohne UI nutzbar. IProgress<T> ist eine saubere, standardisierte Schnittstelle, damit:
- WinForms/WPF automatisch thread-sicher updaten,
- Console/Service/Logger ebenfalls Fortschritt bekommen,
- ohne dass Sie eine eigene Event-Flut oder UI-Abhängigkeiten im Core erzwingen.
3) Async-first Schritte
Falls Sie mittelfristig Steps als Func<CancellationToken, Task> (oder ähnlich) unterstützen wollen: IProgress<T> passt perfekt zu async/await.
Wann es eher nicht lohnt
Wenn Ihr UI/Engine ohnehin schon:
- bei jedem Step-Start/Step-Ende Events feuert,
- die Fortschrittsanzeige primär „Stepweise“ ist (nicht innerhalb eines Steps),
- und Sie keine externen „Long-running“ Operationen mit echtem Prozentwert haben,
…dann ist Progress<T> hauptsächlich „nice to have“, aber wenig Mehrwert.
Vorschlag: Minimal-invasive Erweiterung (backwards compatible)
Ziel: Kein Breaking Change, aber IProgress<> optional.
- Definieren Sie ein neutrales Progress-DTO, z. B.:
-
TaskProgressInfo
BundleName/Id, ItemName/Id, StepName/Id
Phase (Starting/Running/Completed/Failed/Rollback…)
- optional:
Percent (nullable), Message, Exception (optional)
- Erweitern Sie den Executor um einen optionalen Parameter:
ExecuteAsync(..., IProgress<TaskProgressInfo>? progress = null, CancellationToken ct = default)
- Standard-Progress aus Ihrer Engine:
- Bei Step-Start:
progress?.Report(... Starting ...)
- Bei Step-Ende:
... Completed/Failed ...
- Sub-Progress ermöglichen:
- Entweder: Step-Delegate bekommt
IProgress<TaskProgressInfo> injiziert
- oder: Steps implementieren ein Interface wie
IProgressReportingStep, das die Engine beim Ausführen mit progress versorgt.
Damit können Ihre bestehenden WinForms-Controls einfach einen Progress<TaskProgressInfo> anlegen und UI updaten – ohne Cross-Thread-Basteln.
Wenn Sie mir sagen, ob Sie eher „Stepweise Progress“ oder „Sub-Progress innerhalb Steps“ brauchen, kann ich Ihnen eine konkrete API-Skizze machen (inkl. Namensvorschlägen, Datenmodell und wie das sauber mit Rollback-Phasen zusammenspielt).
Question: In CompuMaster.TaskManagement könnte man evtl. - falls dort überhaupt sinnvoll - diese Funktionalität nachrüsten. Die Frage ist: macht es überhaupt dort Sinn?
Ja, das kann in
CompuMaster.TaskManagementsinnvoll sein – aber nicht zwingend. Es hängt davon ab, welches Progress-Szenario Sie dort abdecken möchten.Aus Ihrem README ist klar: Die Library modelliert bereits TaskBundles → TaskItems → TaskSteps, inkl. Rollback/Fail-Strategien, geschätzter Dauer, Abbruch und optionaler WinForms-UI. ([GitHub]1)
Damit haben Sie schon eine “Progress-Struktur” (Step-Start/Step-Ende, Status, Timing).
System.Progress<T>wäre also kein Muss, sondern eher ein Adapter/Komfort-Feature.Wann
Progress<T>dort wirklich Sinn macht1) „Sub-Progress innerhalb eines einzelnen Steps“
Aktuell ist ein Step „atomar“ gedacht (“A task step is an atomic step…”). ([GitHub]1)
Wenn Sie aber Steps haben wie „Datei kopieren“, „DB-Migration“, „Download“, dann will man innerhalb eines Steps z. B. 0–100% melden (und nicht nur „Step läuft / Step fertig“).
→ Hier ist
IProgress<T>Gold wert, weil der Step-Implementierer progress melden kann, ohne die UI zu kennen.2) UI-/Host-agnostische Progress-Ausgabe
Sie haben WinForms-UI im Repo, aber die Core-Library ist auch ohne UI nutzbar.
IProgress<T>ist eine saubere, standardisierte Schnittstelle, damit:3) Async-first Schritte
Falls Sie mittelfristig Steps als
Func<CancellationToken, Task>(oder ähnlich) unterstützen wollen:IProgress<T>passt perfekt zuasync/await.Wann es eher nicht lohnt
Wenn Ihr UI/Engine ohnehin schon:
…dann ist
Progress<T>hauptsächlich „nice to have“, aber wenig Mehrwert.Vorschlag: Minimal-invasive Erweiterung (backwards compatible)
Ziel: Kein Breaking Change, aber
IProgress<>optional.TaskProgressInfoBundleName/Id,ItemName/Id,StepName/IdPhase(Starting/Running/Completed/Failed/Rollback…)Percent(nullable),Message,Exception(optional)ExecuteAsync(..., IProgress<TaskProgressInfo>? progress = null, CancellationToken ct = default)progress?.Report(... Starting ...)... Completed/Failed ...IProgress<TaskProgressInfo>injiziertIProgressReportingStep, das die Engine beim Ausführen mitprogressversorgt.Damit können Ihre bestehenden WinForms-Controls einfach einen
Progress<TaskProgressInfo>anlegen und UI updaten – ohne Cross-Thread-Basteln.Wenn Sie mir sagen, ob Sie eher „Stepweise Progress“ oder „Sub-Progress innerhalb Steps“ brauchen, kann ich Ihnen eine konkrete API-Skizze machen (inkl. Namensvorschlägen, Datenmodell und wie das sauber mit Rollback-Phasen zusammenspielt).