DataBinding und ArrayList

An sich nur eine kleine Sache, aber ich beschreibe sie trotzdem mal kurz – vielleicht hilft’s dem einen oder anderen, das Problem schneller zu lösen:

Eine DataGridView, angesetzt per DataBinding auf eine ArrayList, die in meinem Programm immer funktioniert hatte, wollte plötzlich nicht mehr: Im Grid fehlten die Kolonnen. Keine Fehlermeldung, keine Exception, einfach keine Kolonnen mehr, das DataBinding versagte.

Der Grund war ganz einfach: Vor diesem Problem war es immer so gewesen, dass zum Zeitpunkt des Erzeugens der DataGridView sich mindestens 1 Element in der ArrayList befand. Jetzt war sie leer. Da ArrayList völlig untypisiert ist, hat ohne mindestens 1 Element in der Liste der DataBinding-Mechanismus absolut nichts, womit er arbeiten kann, und das Grid bekommt keine Kolonnen. (Und dass das Grid nach dem Auftauchen des ersten Elements die Bildung von Kolonnen nachholt, ist zugegebenermassen etwas viel verlangt.)

Eine Umstellung von ArrayList auf eine typisierte List<T> behob das Problem.

Bei einer Google-Suche nach dem Problem stiess ich noch auf ein mit bisher unbekanntes Interface ITypedList, beschrieben in diesem Blog-Eintrag. Damit scheint eine Feinkontrolle des DataBinding möglich zu sein; ich muss aber zugeben, dass ich die Sache noch nicht im Detail studiert habe.

Und dann noch dies: Es muss nicht immer Google sein. Selbst in den heutigen Zeiten gibt es Leute, welche fleissig Links sammeln und Web Directories pflegen. Wenn Sie mal ein paar neue Blogs zum Thema .NET probelesen wollen, finden Sie hier gegen 100 Stück – ich denke nicht, dass Sie die alle schon kennen…

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

Zugriff auf unterschiedliche Datenbank-Server

Vielleicht ist das, worüber ich hier schreibe, für Sie bereits ein alter Hut, weil es schon im Framework 2.0 eingeführt wurde, aber vielleicht kennen Sie es ja noch nicht, weil Microsoft die Sache nicht an die grosse Glocke hängt:

In unserem Entwicklungswerkzeug EMBASSY waren wir es gewohnt, mit Hilfe von ODBC generisch auf verschiedene Datenbank-Server zuzugreifen, konkret vor allem auf Microsoft SQL Server und Oracle. Das ist ja zum grossen Teil überhaupt der Witz einer Treiber-artigen Schnittstelle wie ODBC, dass Dinge abstrahiert werden und so eine weitgehend generische Programmierung möglich wird.

Umso überraschter waren wir damals bei einem Blick auf das .NET Framework 1.1, dass eine solche Abstraktions-Ebene nicht in Sicht war. Gemäss Microsoft das bevorzugte Mittel, um auf Datenbank-Server zuzugreifen: auf den jeweiligen Server zugeschnittene, spezifische eigene Klassen, also Klassen wie SqlConnection und OracleConnection, SqlCommand und OracleCommand, usw.

Auf der einen Seite sind solche massgeschneiderten Klassen natürlich hübsch, aber auf der anderen Seite eben ein Hindernis beim Versuch, ein Programm zu schreiben, dass via einfache Konfigurations-Angabe von einem Server-Typ auf einen anderen wechseln kann. Und ja, auch klar, dass Microsoft nicht unbedingt möchte, dass alle Programme ganz einfach vom hauseigenen SQL Server auf das Konkurrenz-Produkt Oracle umschaltbar sind, aber dass die Hürde dann gleich so gross herauskommt?

Glücklicherweise hatte Microsoft bereits bei der Version 2.0 des Framework ein Einsehen: Das Zauberwort heisst DbProviderFactory. Eine DbProviderFactory offeriert Methoden, wie man auf generische Weise zu Connection-Objekten, Command-Objekten usw. kommt.

Die Methode GetFactory der statischen Klasse DbProviderFactories dient dazu, eine DbProviderFactory zu beschaffen, wenn man den Namen des Providers kennt, also z.B. System.Data.OracleClient.

Natürlich geht es bei jedem nicht-trivialen Programm nicht komplett ohne das Wissen, auf welchem Typ Server man gerade arbeitet, denn es bleiben Unterschiede bei den unterstützten Datentypen, bei einigen SQL-Anweisungen wie z.B. CREATE TABLE, und bei den auftretenden Exceptions, um die man sich explizite kümmern muss, aber über weite Strecken wird der Code dank den „Factories“ tatsächlich frei von Fallunterscheidungen.

Veröffentlicht in Keine Kategorie. Schlagwörter: , . Leave a Comment »

IBindingList

Im Rahmen der Erstellung eines Prototyps hatte ich es mit einem DataGridView zu tun, der mit DataBinding arbeiten sollte, aber nicht auf einer Datenbank, sondern auf Daten im Speicher.

Das klappte zunächst ganz gut, dank der grossen Flexibilität des DataGridView-Controls, das unter anderem auf allem aufsetzen kann, was das IList-Interface aufweist. Dann aber tauchte die Frage auf: Wie merkt der DataGridView, wenn an den zugrundeliegenden Daten etwas ändert, d.h. in der Liste Elemente dazukommen oder gelöscht werden, damit das Nachführen auf dem Bildschirm klappt?

Schnell einmal war klar, dass es nicht „einfach so“ klappt, durch irgendetwas, was ein Objekt tut, welches das IList-Interface implementiert, oder dadurch, dass sich der DataGridView bei der Liste irgendwie einklinkt.

Oft braucht es nur einen Hinweis auf die richtige Spur, und wer sich mit dem .NET-Framework einigermassen auskennt, findet den Weg dann alleine. Deshalb keine grosse Ausschweifungen, sondern nur ein Stichwort für Leser, die vor derselben Frage stehen: IBindingList heisst das Lösungswort.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »