Hi,

ich bin neu in Sachen .Net und C# und daher noch etwas orientierungslos bei den vielen Möglichkeiten. Somit ist mein Anliegen vielleicht auch völlig Simpel, da es schon einen Standard Weg gibt. Auf jeden Fall würde ich mich freuen, wenn ein paar alte Hasen mich in die richtige Spur schubsen würden.

Ich habe ein kleines Testprojekt, dass unter anderen ein paar Zahlen aus einer Datenbank holt und diese in Diagrammen darstellt. Nun möchte ich nicht, dass mein User solange warten muss, bis alle Daten da sind, bevor er arbeiten kann.

Daher ist meine Idee, die eigentliche Datenbankanfrage in einem eigenen Thread laufen zu lassen und das Ergebnis erst dann in die an das WPF-Control gebundene Datenquelle überträgt.

Nun habe ich leider noch keinen annähernd kompletten Überblick über die in C# vorhandenen Möglichkeiten einen Thread zu erstellen, nach einem oberflächlichen einlesen scheint mir aber der BackgroundWorker ein guter Kandidat dafür zu sein, insbesondere weil ich über das Ende der Arbeit informiert werde.

Bevor ich mich aber an die Arbeit für etwas mache, dass es vielleicht schon viel Besser und einfacher gibt wollte ich gerne eine Einschätzung zu der Idee von Leuten die sich damit auskennen. Also Gibt es vielleicht eine (ADO).NET Technik, die das von sich aus schon kann? Oder ist der Background worker völlig ungeeignet? Gibt es Fallstricke die ich beachten muss (ich nehme z. B. mal an, jeder Thread wird seine eigne Connection zur Datenbank öffnen)?

Ich weiß, dass ganze ist noch nicht sehr technisch, aber ich hoffe das hier nicht nur nach Wissen, sondern auch nach Erfahrungen gefragt werden darf .

Zitat:

Ich habe ein kleines Testprojekt, dass unter anderen ein paar Zahlen aus einer Datenbank holt und diese in Diagrammen darstellt. Nun möchte ich nicht, dass mein User solange warten muss, bis alle Daten da sind, bevor er arbeiten kann.

Wieviele Zahlen sind denn ein Paar Wenn es tatsächlich nur en paar sind hättest du das Problem vermutlich nicht.

Zitat:

Oder ist der Background worker völlig ungeeignet?

Jede Möglichkeit eine Thread zu benutzen ist hier vermutlich gleich geeignet. Die Implementierung wird eher problematisch sein. Je nachdem wie du auf die Datenbank zugreifst und Daten holst hast du gar keine Möglichkeit den Thread sinnvoll zu benutzen (jenseits von die GUI bleibt reaktionsfähig). Die Implementierung muß ja in irgendeinerweise Blöcke von Daten aus der Datenbank holen damit du Teile an den GUI Thread (den Hauptthread) weitergeben kannst. Alles ununterbrechbar in einem Rutsch holen wird dir kaum weiterhelfen.

Wobei BackgroundWorker und WPF nicht so ganz zusammenpsst. Backgroundworker stammt eher aus der Winforms Welt. Er würde natürlich genauso funktionieren es fühlt sich nur gerade nicht nach dem passenden Mittel an. War in WPF nicht eher der Dispatcher die Waffe der Wahl?

Hallo,

und Danke für die Antwort.

Ralf Jansen hat folgendes geschrieben :

Wieviele Zahlen sind denn ein Paar Wenn es tatsächlich nur en paar sind hättest du das Problem vermutlich nicht.

Momentan sind es ca. 1,5 Millionen Datensätze die je nach (Diagramm-) Darstellung unterschiedlich in Relation zueinander stehen. Allerdings sind dies momentan Phantasiewerte. Mein Test Projekt dient tatsächlich nur der Technologiestudie, allerdings in Vorbereitung auf ein echtes Projekt, welche dann mit einem ständig wachsenden Datenbestand umgehen muss. Die jetzige Datenmenge sollte da nach ca. 2 Jahren vorliegen.

Ralf Jansen hat folgendes geschrieben :

Jede Möglichkeit eine Thread zu benutzen ist hier vermutlich gleich geeignet. Die Implementierung wird eher problematisch sein. Je nachdem wie du auf die Datenbank zugreifst und Daten holst hast du gar keine Möglichkeit den Thread sinnvoll zu benutzen (jenseits von die GUI bleibt reaktionsfähig). Die Implementierung muß ja in irgendeinerweise Blöcke von Daten aus der Datenbank holen damit du Teile an den GUI Thread (den Hauptthread) weitergeben kannst. Alles ununterbrechbar in einem Rutsch holen wird dir kaum weiterhelfen.

Die Idee ist hier tatsächlich nur die reine Abfrage an die Datenbank zu parallelisieren, da gerade beim Programmstart, einige davon gleichzeitig erfolgen werden und diese potentiell Zeitaufwändiger sein können. Das dass übergeben an den Hauptthread diesen dann wieder blockiert ist klar, die einzelnen Abfragen sind aber alle eigenständig und nicht voneinander abhängig, daher sollten sie sich eigentlich gut parallelisieren lassen.

Meine Idee geht in die Richtung mir ein Objekt zu schaffen, welches ich mit einem "lesneden" querry bestücke (eventuell schon als argument für den Constructor), welches dann in einem eigenen Thread dieses Querry ausführt und mir das Ergebnis in einer möglichst universellen Form zurückgibt (reader?, DataSet?) und danach am ende seines Lebenszyklus angekommen ist. Es würde also auf 1 Query = 1 Thread hinaus laufen, welcher wie schnell fertig ist wäre egal da nach und nach alle Ansichten aktualisiert würden.

Ralf Jansen hat folgendes geschrieben :

Wobei BackgroundWorker und WPF nicht so ganz zusammenpsst. Backgroundworker stammt eher aus der Winforms Welt. Er würde natürlich genauso funktionieren es fühlt sich nur gerade nicht nach dem passenden Mittel an. War in WPF nicht eher der Dispatcher die Waffe der Wahl?

Danke für diesen Hinweis. Genau dass sind die Erfahrungen auf die ich hier hoffe. Ich weiß aus anderen Sprachen, wie es sich anfühlt, wenn Techniken die zu einem zweck gedacht sind für einen anderen vergewaltigt werden, obwohl es für den anderen Zweck eine eben solche gibt. Ich bin im .NET Bereich nur viel zu grün hinter den Ohren um das selbst zu erkennen.

Zitat:

(reader?, DataSet?)

Beides würde ich eher nicht nehmen. Den Reader und damit die Connection die da dran hängt benutzt du dann plötzlich threadübergreifen was nicht gesund ist.
Und ich vermute mal das du die Teilergebnisse irgendwie zusammenführen willst dann wäre das bei einem DataSet/DataTable glaube ich eher aufwendig (nur eine Vermutung solltest du vielleicht ausprobieren). Wenn du die Daten nicht in einer bearbeitbaren Datatable brauchst würde ich die Daten irgendwie geeignet umfüllen. Um die Daten imn ein Diagramm zu bekomemn benutzt du ja vermutlich auch nicht direkt dir DataRows?

Hallo noch einmal,

Ralf Jansen hat folgendes geschrieben :

Zitat: (reader?, DataSet?) Beides würde ich eher nicht nehmen. Den Reader und damit die Connection die da dran hängt benutzt du dann plötzlich threadübergreifen was nicht gesund ist. Und ich vermute mal das du die Teilergebnisse irgendwie zusammenführen willst dann wäre das bei einem DataSet/DataTable glaube ich eher aufwendig (nur eine Vermutung solltest du vielleicht ausprobieren). Wenn du die Daten nicht in einer bearbeitbaren Datatable brauchst würde ich die Daten irgendwie geeignet umfüllen. Um die Daten imn ein Diagramm zu bekomemn benutzt du ja vermutlich auch nicht direkt dir DataRows?

Das mit der Connection ist natürlich ein Argument .

Das geeignete umfüllen hatte ich eigentlich im Haupthread gesehen, damit ich das Asyncrone-Query-Objekt möglichst universell nutzen kann. Aber vielleicht währen hier mehrere Nachfahren eines Basis Objektes gar keine schlechte Idee, so würde immerhin mehr Arbeit im freien Thread erledigt. Da wir hier nicht über hunderte Threads, sondern vielleicht über zehn reden, dürfte sich der Aufwand in grenzen halten.

Und ja es geht um rein lesende Zugriffe.

Danke für die Unterstützung!