Best practice Timer: System.Timer, Backgground Worker oder Dispatchertimer

  • WPF

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von NetJunkie.

    Best practice Timer: System.Timer, Backgground Worker oder Dispatchertimer

    Hallo,
    ich habe eine WPF Anwendung (brav im MVVM Pattern), die nun mehrere Timer beinhalten soll, die das UI nicht stören sollen.

    Die Timer a und b sollen im 5 Minuten Takt versetzt zu einander (d.h. der erste startet sofort, der zweite in 2,5 Minuten) unterschiedliche aufwändigere Datenbankübertragungen durchführen. Beide Timerevents brauchen somit überhaupt nicht auf das Viewmodel oder die UI zuzugreifen, sind also unabhängig.

    Ein Timer c überprüft alle 2 Sekunden einen Wert in dern Datenbank und macht dann auch was aufwändigeres mit der Datenbank ohne Bezug zum VM oder UI.

    Ein Timer d soll nach 30 Sekunden Nichtbenutzung der UI, diverse Eingaben in der UI löschen, also im VM die entsprechenden Bindings leeren.

    Für den letzten Timer d, denke ich, ist der Dipatchertimer die beste Wahl, da ich ja hier auf das VM zugreifen muß.

    Für die Timer a und b habe ich im ersten Versuch jeweils einen System.Timer verwendet. Das klappt auch. Hier habe ich nur sorge, dass falls noch mehr Timer kommen, ich alles mit immer neuen Threads zumülle. Oder stört das nicht?

    Mit welcher Variante würdet Ihr die Timer programmieren? ?(
    ist glaub egal, hauptsache im eigenen Thread.
    Und nicht mit Backgroundworker arbeiten - das ist zum einen gar kein Timer, zum andern belegt der unnötig Resource.
    Fraglich ist auch, warum du so viele Timer brauchst. Generell würde ich versuchen, die iwie zusammenzulegen, also zB statt 2 versetzt laufender, im 5 min - Takt einen einzigen, im 2,5min Takt. Es sei denn, deren Jobs überlappen sich, und du willst halt mehrere Cpu-Kerne ausnutzen (falls das möglich ist).
    Aber im grossen und ganzen alles ziemlich piepe.