Der (Microsoft) Office Doktor und Softwarearchitekt

Gerade für Einsteiger warten bei der Programmierung in .NET so einige Fallen. So ist es beispielsweise nicht immer leicht, auf Anhieb den Datentyp eines Objekts zu ermitteln. Dazu ein praktisches Beispiel:

In ein Formular wurde eine ComboBox eingebaut und über eine DataTable mit Daten gefüllt. Beim Klick auf eine Schaltfläche soll nun der Wert einer nicht angezeigten Spalte ermittelt und ausgegeben werden. Dabei stellt sich die Frage, über welche Eigenschaft oder Methode nun auf die Datenzeile der ComboBox zugegriffen werden kann. Mit Hilfe von IntelliSense lässt man sich mit “this.ComboBox.” nun die möglichen Einträge anzeigen, und sieht sich in der QuickInfo an, was die jeweilige Eigenschaft bzw. Methode zurückgibt.

Nun wissen wir, dass die aktuelle Datenzeile über this.ComboBox.SelectedItem zurückgegeben werden kann. Doch wie kommt jemand darauf, der sich noch nicht so gut auskennt? Die QuickInfo für diesen Eintrag zeigt an, dass der Rückgabewert vom Typ “object” ist.

Wie kommt man nun darauf, dass SelectedItem eine DataRowView darstellt?
Mit einem einfachen Trick!

Wir schreiben in unser Ereignis einfach ein

MessageBox.Show(this.ComboBox.SelectedItem.ToString());

Wenn wir die Anwendung nun starten und den Wert abrufen, können wir in der MessageBox den Text

System.Data.DataRowView

lesen.

Es ist also möglich, den jeweiligen Datentyp eines Rückgabewertes zu entschlüsseln. Leider muss man dazu manchmal einen kleinen Umweg gehen. Das ist zwar nicht schön, aber immerhin gibt es eine Möglichkeit, an die gewünschte Information zu gelangen.

Als alter VBA-Entwickler bin ich immer noch begeistert von dem, was Microsoft Access so alles bietet. Anders als in VB 6, dem alten DataGrid in .NET 1.1 und der aktuellen DataGridView in .NET 2.0/3.0 kann die Listbox in Microsoft Access riesige Datenmengen anzeigen ohne auch nur mit der sprichwörtlichen Wimper zu zucken.

Beim Ladevorgang werden die Daten dabei Stück für Stück eingelesen, so dass sich die ersten Zeilen der Listbox augenscheinlich sofort füllen. Der Anwender hat den Eindruck, die Daten wären nach nur wenigen Millisekunden bereits verfügbar. Und tatsächlich kann der Anwender bereits mit den Daten arbeiten. Er kann beispielsweise eine Zeile markieren oder einen Bildlauf auf die Liste ausführen, obwohl im Hintergrund noch Daten nachgeladen werden.

Die DataGridView arbeitet leider nicht so. Das hat damit zu tun, dass das ganze .NET Framework auf die Arbeit mit Offline-Daten ausgelegt ist. Die DataGridView selbst kann Daten sehr performant anzeigen. Das rührt daher, dass sie als Datenquelle Daten aus bereits vorhandenen (!) Objekten erwartet, die eine der Schnittstellen IList, IListSource, IBindingList oder IBindingListView implementiert haben. Sobald man ein entsprechendes Objekt als Datenquelle ankoppelt, braucht die DataGridView die im Objekt gespeicherten Daten nur noch auf den Bildschirm zu zeichnen.

Das Problem ist also immer das Laden der Daten vom Speichermedium in den Arbeitsspeicher (also in das entsprechende Objekt, wie z.B. eine DataTable oder ein Array). Der gesamte Vorgang besteht also aus zwei Schritten: Erst die Daten in das Objekt laden, dann das Objekt an die DataGridView binden. Der Anwender hat dabei den Eindruck als stünde jemand auf der Leitung.

Daher habe ich mich entschieden, den Anwender mit einem Trick zu vertrösten. Ich teile die Arbeit auf und lade zunächst nur 100 Datensätze in das Objekt, die dem Anwender anschliessend in der DataGridView präsentiert werden. Während dieser dann schon mal beginnt, sich mit den Daten zu beschäftigen, lade ich einfach die komplette Datenmenge und stelle die DataGridView.DataSource dann noch einmal neu ein.

Natürlich ist das keinesfalls die eierlegende Wollmilchsau. Die Praxis zeigt aber, dass die Anwender gut mit diesem Trick leben können. Letzendlich dauert es meist nur einige Sekunden, bis die volle Datenmenge geladen ist. Solange ist man allemale mit dem ersten Eindruck auf dem Bildschirm beschäftigt.

Wer sich näher mit der Performance-Problematik bei DataGridViews beschäftigen möchte sei noch auf zwei interessante Seiten im www hingewiesen:

René Brunner zeigt, wie man beliebig große Daten performant verarbeiten kann (Ich selbst konnte mich mit dieser Lösung nicht anfreunden, weil man unendlich viel codieren muss)

http://megos.wordpress.com/2008/07/19/die-millionen-datagridview 

Frank Dzaebel zeigt, wie performant die DataGridView selbst bei großen Mengen wie 200.000 Zeilen noch ist. Zu berücksichtigen ist dabei allerdings, dass er die Daten nicht von der Festplatte in ein Objekt lädt, sondern OnTheFly im Arbeitsspeicher in einem Array erzeugt. Daher war auch dieser Ansatz für mich nicht relevant. Trotzdem eine sehr schöne Recherche, wie ich finde.

http://dzaebel.net/DgvVirtual.htm

Bei einer Recherche zu Tipps und Tricks bei der Erstellung von Windows Formularen unter .NET bin ich auf eine interessante Seite gestoßen: George Shepherd’s Windows Forms FAQ.

Viel Erfolg beim Ausprobieren der Tipps und Tricks!

Link: George Shepherd’s Windows Forms FAQ