Forums Neueste Beiträge
 

Wrapper für ADO.NET Dataset/DataTable nach ADODB.Recordset

29/08/2007 - 17:33 von Josef Poetzl | Report spam
Hallo!

Meine bisherigen Sucherfolge bei Google & Co liegen bei Null.
Das kann natürlich auch daran liegen, dass ich falsch suche. ;-)
Aber vielleicht kann mir hier jemand einen Tipp geben.

Ich suche einen Wrapper (DataTable nach ADODB.Recordset) o.à., um ein
Access-Userinterface mit ADO.Net-Datenzugriffen zu bedienen, da ich
den Business- u. Datenlayer einer Anwendung auf ADO.Net umstellen
will.
Spàter soll ein .net-Userinface dazukommen.
Es muss aber auch das aktuell eingesetzte Access-Frontend weiterhin
versorgt werden können.

Derzeitige Aufteilung:
UI: Access-FE (von Kunden individuell erweiterbar)
BI+DL: COM-dll stellt über ADODB.Recordset (bzw. DAO.Recordset) dem
Access-FE die Daten zur Verfügung. (Die eigentliche Datenprüfung
erfolgt im SQL-Server.)

mein Ziel:
UI: Access-FE + .net-Windows-Forms-Anwendung
BL+DL: .net-Assemblies

Die .net-Assemblies sollen vollstàndig .net-basierend sein. Ich will
dort kein ADODB verwenden. Damit ich aber dem Access-FE ein
ADODB.Recordset zur Verfügung stellen kann, dachte ich mir, ich nehme
das .net-Assembly als Basis für ein weiteres Assembly, das ich um die
ADODB-Methoden ergànze und als COM-dll zur Verfügung stelle.

ADODB.Recordset muss vollstàndig steuerbar sein. (lesen, àndern,
anfügen, löschen)
Nur Lesend ist relativ unkomplizert umzusetzen, da ich in diesem Fall
ein ungebundenes ADODB.Recordset mit Daten befüllen könnte.

Mein derzeitiger Ansatz ist eine eigene ADODB.Recordset-Klasse (mit
implementierter ADODB.Recordset-Schnittstelle) von dem ein Objekt
statt dem "orginal" ADODB.Recordset weitergebe.
Diese eigene Klasse arbeitet aber z.B. intern wie ein
Dataset/DataTable.

Eine andere Variante wàre: ein ungebundenes ADODB.Recordset zu
befüllen, die Änderungsereignisse abzufangen und an Dataset/DataTable
weiterzureichen.

In der Access-Anwendung würde ich z.B. in einem Formular so etwas
àhnliches nutzen wollen: (nur Prinzipdarstellung)
Me.Recordset = BL.Personen.Liste.ADODB.Recordset
oder
Me.Recordset MeinWrapper.getAdodbRecordset(BL.Personen.Liste.DataTable)

Ich vermute so ein àhnliches Vorhaben ist schon öfter aufgetreten. Nur
ich finde nichts.
Kennt jemand einen fertigen Wrapper, der so etwas àhnliches macht?

Ich probiert auch schon ein wenig mit der selbst geschriebenen
Recordset-Klasse herum. Das funktioniert auch einigermaßen, nur sind
sehr viele Zusatzklassen zu ergànzen um volle
Schnittstellentauglichkeit für Access zu gewàhrleisten.
Um diesen Aufwand etwas zu minimieren, hoffe ich auf eine vorhandene
Bibliothek. (Darf auch ein kommerzielles Produkt sein.)

Vielleicht gibt es einen noch viel einfacheren Weg, an den ich nicht
denke.

mfg
Josef
 

Lesen sie die antworten

#1 Asus
18/09/2007 - 13:56 | Warnen spam
Hallo,

versuche doch einfach mal in VS2005 einen Verweis auf "ADODB.dll"
hinzuzufügen, dann hast du die kompletten ADO ActiveX Komponenten verfügbar.
Dies macht übrigens auch der VB-Code-Konverter von VS2005 so.

Gruß
Sven

"Josef Poetzl" wrote:

Hallo!

Meine bisherigen Sucherfolge bei Google & Co liegen bei Null.
Das kann natürlich auch daran liegen, dass ich falsch suche. ;-)
Aber vielleicht kann mir hier jemand einen Tipp geben.

Ich suche einen Wrapper (DataTable nach ADODB.Recordset) o.à., um ein
Access-Userinterface mit ADO.Net-Datenzugriffen zu bedienen, da ich
den Business- u. Datenlayer einer Anwendung auf ADO.Net umstellen
will.
Spàter soll ein .net-Userinface dazukommen.
Es muss aber auch das aktuell eingesetzte Access-Frontend weiterhin
versorgt werden können.

Derzeitige Aufteilung:
UI: Access-FE (von Kunden individuell erweiterbar)
BI+DL: COM-dll stellt über ADODB.Recordset (bzw. DAO.Recordset) dem
Access-FE die Daten zur Verfügung. (Die eigentliche Datenprüfung
erfolgt im SQL-Server.)

mein Ziel:
UI: Access-FE + .net-Windows-Forms-Anwendung
BL+DL: .net-Assemblies

Die .net-Assemblies sollen vollstàndig .net-basierend sein. Ich will
dort kein ADODB verwenden. Damit ich aber dem Access-FE ein
ADODB.Recordset zur Verfügung stellen kann, dachte ich mir, ich nehme
das .net-Assembly als Basis für ein weiteres Assembly, das ich um die
ADODB-Methoden ergànze und als COM-dll zur Verfügung stelle.

ADODB.Recordset muss vollstàndig steuerbar sein. (lesen, àndern,
anfügen, löschen)
Nur Lesend ist relativ unkomplizert umzusetzen, da ich in diesem Fall
ein ungebundenes ADODB.Recordset mit Daten befüllen könnte.

Mein derzeitiger Ansatz ist eine eigene ADODB.Recordset-Klasse (mit
implementierter ADODB.Recordset-Schnittstelle) von dem ein Objekt
statt dem "orginal" ADODB.Recordset weitergebe.
Diese eigene Klasse arbeitet aber z.B. intern wie ein
Dataset/DataTable.

Eine andere Variante wàre: ein ungebundenes ADODB.Recordset zu
befüllen, die Änderungsereignisse abzufangen und an Dataset/DataTable
weiterzureichen.

In der Access-Anwendung würde ich z.B. in einem Formular so etwas
àhnliches nutzen wollen: (nur Prinzipdarstellung)
Me.Recordset = BL.Personen.Liste.ADODB.Recordset
oder
Me.Recordset > MeinWrapper.getAdodbRecordset(BL.Personen.Liste.DataTable)

Ich vermute so ein àhnliches Vorhaben ist schon öfter aufgetreten. Nur
ich finde nichts.
Kennt jemand einen fertigen Wrapper, der so etwas àhnliches macht?

Ich probiert auch schon ein wenig mit der selbst geschriebenen
Recordset-Klasse herum. Das funktioniert auch einigermaßen, nur sind
sehr viele Zusatzklassen zu ergànzen um volle
Schnittstellentauglichkeit für Access zu gewàhrleisten.
Um diesen Aufwand etwas zu minimieren, hoffe ich auf eine vorhandene
Bibliothek. (Darf auch ein kommerzielles Produkt sein.)

Vielleicht gibt es einen noch viel einfacheren Weg, an den ich nicht
denke.

mfg
Josef

Ähnliche fragen