Unterschied zwischen Benutzung von Async Sub und Async Task(of Type)

Es muss halt irgendeinen Loading State geben. Daher braucht man halt ein default value, das Ladestatus impliziert oder einen generellen Ladestatus im Formular (je nach Fall). Aber ja, wohl aus dem Grund gibt es keine async properties, weil es semantisch eben keinen Sinn macht. Wenn man die unterschiedlichen Status fest definieren würde, könnte man Properties sich so verhalten lassen. Aber das trifft zu viele Annahmen. Daher wurde das denke ich (verständlicherweise) nicht gemacht.

Grüße

Warum brauchst du jetzt noch das Event? Das ist eigentlich redundant. Du kannst doch auch in der Methode direkt die Property setzen. Im Endeffekt machst du jetzt nichts anderes, außer dass du noch den Weg über ein Event zusätzlich gehst. Dieses wird manuell im selben Thread von dir geworfen und bringt somit an der Stelle keinen Mehrwert, weil du den Handlercode direkt integrieren kannst. Du deabonnierst es schließlich auch direkt wieder. Events machen ja nur Sinn, wenn andere Instanzen etwas mitkriegen wollen oder du z.B. asynchrone Arbeit mit dem EAP abfangen willst. Innerhalb derselben Klasse hast du ja eh schon die volle Kontrolle sonst.

Deine Property wirft ja auch PropertyChanged für die UI, d.h. da musst du ja sonst auch nichts an irgendein Event binden.

Viele Grüße

@kafffee

So hab ich das nicht gemeint. Wie kommt denn das fertige Gericht als "Argument" vor?

Ich hätte eine Klasse, eine Sub zum starten des Ladens(wie auch abbrechen), diese Stellt das Event zur verfügung, wenn fertig das Event feuern, aber auch eigene "EventArgs" nutzen, so kommt mit dem Event alles rein. So ist das ausreichend abgekapselt und du kannst das dann auch wieder verwenden. Was bei deinem Code nicht drin wäre. "Reusable Code" sollte man anlegen, Spaghetti vergessen, egal wie gut das schmeckt.

Genau so würde ich es nicht machen. EAP ist veraltet. Task-basierte Operationen sind schon korrekt. Nur wurden sie hier halt mit Events vermischt, die hier eigentlich nicht nötig sind.
Im gesamten .NET-Bereich ist TAP auch der neue Standard. Events mit eigenen EventArgs für asynchrone Operationen (Progress, Complete, ...) findet man in der aktuellen API evtl. nur noch aus Legacy-Gründen. Aber sie werden auch nicht mehr beworben. Ist halt n Standard von vor 10 Jahren.

Viele Grüße

Trade schrieb:

Ist halt n Standard von vor 10 Jahren.

OK hast mich überzeugt. Ich bin bei NET wirklich noch auf einem älteren Stand, werde mir mal 1-2 Bücher kommen lassen. Bei Android hab ich es nicht bereut aufs neueste umzusteigen (Kotlin und auch Jetpack-Compose), sicher wirds auch Vorteile in NET haben aktuelleres zu nutzen.

Ja, EAP hatte schon seine Daseinsberechtigung. Es war damals einfach gängig, um sowas abzubilden. Hab's selbst auch oft benutzt. Gerade weil mir das mit Async-Await usw. nicht so geläufig war. Aber TAP ist einfach eine sehr mächtige Technik und inzwischen de-facto Standard in .NET. Man kann halt mit einfacherer Methodenstruktur nun auf asynchrone Aufgaben warten und diese auch repräsentativ durch den Code durchreichen mit Tasks. Du musst halt nicht mehr Wartelogik auf mehrere Methodenausführungen verteilen.

Als ich angefangen habe mit .NET (Framework) war es irgendwie ein Weg sich mit Thread-Joining oder ManualResetEvents zu behelfen und das hat schon irgendwie dann mal funktioniert, aber war eher so semi-toll. Davon abgesehen musste man halt an so vielen Stellen (auch mit dem EAP noch) BeginInvoke aufrufen, weil die Delegaten dann auf Handler zeigen, die nicht mehr im UI-Thread laufen und lauter solche Sachen. Da ist das schon wesentlich angenehmer nun, weil man primär die Nebenläufigkeit ja wählt, um den UI-Thread zu entblocken, aber trotzdem irgendwie auf das Ergebnis warten wollte. Gab es halt damals in .NET 3.5 und glaube sogar .NET 4 noch nicht. Erst ab 4.5 bzw. 4 mit ner NuGet-Lib. Aus Gründen der Kompatibilität hat man EAP dann oftmals verbaut. Aber das ist ja alles legacy.

Viele Grüße

Das hört sich gut an, allein wenn man sich die ganze "invokerei" spart ist es das auf jeden Fall Wert zu lernen. Das erklärt auch warum man den Webclienten nicht mehr nehmen sollte, da sind die Methoden mit Async im Namen auch noch EAP. Es gab Situationen wo man APM vorziehen sollte(hab grad nicht im Kopf wann), aber ich glaube fast APM ist nicht mehr relevant?

PS.
EIne kleine Recherche brachte mir die Anwort sofort, APM und EAP wurden durch TAP abgelöst, ist mit der TPL mit NET 4 gekommen.
OK, ich nutze noch "Steinzeit-Technik", das wird sich ändern.