.NET Databinding für ADODB.Recordset?

Für den Einstieg in das Schreiben für die dotnetpro hatte ich neulich als Thema gewählt, Databinding für ADODB.Recordset Objekte zu realisieren. Ich wollte Recordsets wie DataTables an WinForms/WebForms UIs binden können. Complex und simple binding wollte ich realisieren.

Nach 1-2 Tagen Herumexperimentieren habe ich das Thema allerdings (vorläufig?) zu den Akten gelegt. Zwei Wege schienen mir grundsätzlich gangbar:

1. Erstellung eines Containers, der selbst gebunden werden kann. Dem Container würde das Recordset zugewiesen und er würde die für´s Databinding notwendigen Schnittstellen implementieren-
2. Erstellung eines Containers, der wie ein XmlDataDocument an ein DataSet gekoppelt werden kann. Bei der Kopplung würde das Recordset im Container in das DataSet kopiert (über OleDbDataAdapter.Fill()) und anschließend über das DataSet gebunden. Veränderungen am DataSet würden über Events im Container abgefangen und an das Recordset weitergeleitet werden - und umgekehrt.

Lösung 2. schien mir schwieriger und ich habe sie wg. der Kürze der Zeit (es war leider ein "Schnellschuss-Artikel" notwendig) nicht ausprobiert.

Lösung 1. habe ich angefangen und ein gutes Stück voran getrieben. Die ganze Zeit habe ich mich allerdings nicht wohl gefühlt. Ein Zeichen dafür war wiederholtes Nachdenken darüber, ob ich für die Bindung die Arten der erlaubten Cursor einschränken sollte. Am liebsten wäre mir gewesen, mich auf disconnected Recordsets zu beschränken. Das wäre aber dem Zwecke einer nahtlosen Bindung von Recordsets, also einer Gleichstellung von ADODB mit ADO.NET in dieser Hinsicht, zuwider gelaufen. Also habe ich versucht, quasi alle Cursor zu erlauben und maximale Databinding-Funktionalität bereit zu stellen (d.h. listen, einzelne Sätze binden und bearbeiten).

Unterm Strich war der Erfolg jedoch bescheiden bzw. der Aufwand schien angesichts der Einschränkungen bei bestimmten Cursorn (z.b. keine Kenntnis über Anzahl der Sätze bei Dynamic Cursor) zu hoch. Mein persönliches Resultat: Gerade weil ein ADODB.Recordset ein Cursor ist (und keine Objekte enthält und eigentlich also auch nicht frei positionierbar ist), wiederspricht es dem Programmiermodell des .NET Databinding. Beide passen einfach nicht gut zusammen. Symbolisiert wird das durch die Eigenschaften Current und Position des Currency Managers für eine Datenquelle. Current verweist auf das aktuelle Objekt in einer Liste von Objekten. Ein Recordset enthält aber weder Objekte, noch sind sie (immer) direkt über einen Index (AbsolutePosition) adressierbar.

Recordset-Databinding in .NET beim Anspruch voller Funktionalität ist daher quasi ein Widerspruch in sich. In Teilen ließe es sich aber wohl doch realisieren, z.B. so wie auch DataReader in ASP.NET bindbar sein.

Als neues Thema für den dotnetpro Artikel habe ich nun die Realisierung einer Komponente zur Speicherung von Anwendungseinstellungen in Angriff genommen.