TDataSet -> System.Data.DataSet Bridge?

**tomaten**

Hallo, hat einer eine Möglichkeit gefunden Daten aus einem TDataSet in ein .NET DataSet zu schieben oder diese zu verbinden. Das würde die Umstellung auf .NET (im Besonderen auf ASP.NET) sehr erleichtern, da nur die DataSet's gewechselt werden müssten, die mit einer sichtbaren ASP.NET Komponente verbunden sind und die als Source ein System.Data.DataSet erwarten. Hat da Borland gepennt und diese Verbindung vergessen? Ich habe noch nichts gefunden, selbst Dr. Bob meinte, man müsse alles überarbeiten! Aber nicht bei meiner Projektgrösse! Kann nicht monatelang darüber abtauchen! dbExpress gibt es ja schliesslich weiter als dbExpress.NET! Wer will schon freiwillig diesen ADO-Kram benutzen?

**Bernhard Geyer**

Zitat von tomaten:

Hallo, hat einer eine Möglichkeit gefunden Daten aus einem TDataSet in ein .NET DataSet zu schieben oder diese zu verbinden. Das würde die Umstellung auf .NET (im Besonderen auf ASP.NET) sehr erleichtern, da nur die DataSet's gewechselt werden müssten, die mit einer sichtbaren ASP.NET Komponente verbunden sind und die als Source ein System.Data.DataSet erwarten. Hat da Borland gepennt und diese Verbindung vergessen? Ich habe noch nichts gefunden, selbst Dr. Bob meinte, man müsse alles überarbeiten! Aber nicht bei meiner Projektgrösse! Kann nicht monatelang darüber abtauchen! dbExpress gibt es ja schliesslich weiter als dbExpress.NET! Wer will schon freiwillig diesen ADO-Kram benutzen?

Borland hat nicht gepennt. Die Konzepte von ADO.NET und TDataset sind zu unterschiedlich.
TDataset arbeitet im verbundenen Zustand, ADO.NET ohne aktive DB-Verbindung. Und ADO.NET ist bei richtiger Verwendung um Welten mächtiger als das was Borland schon seit Jahren mit TDataset bietet.

Und wenn Du schon auf ASP.NET wechselt, so überarbeite deine DB-Schnittstelle auch gleich mit. Oder schreib dir ein Transformer-Klasse die sowas macht (evtl. 'ne Idee für ein OpenSource/Sourceforge-Projekt).

Ist es nicht möglich einen Dekorator über ein System.Data.DataSet zu stülpen, der von einem "TDataSet" ableitet und somit die "Übersetzung" übernimmt?
Wäre es nicht außerdem möglich einfach in den Vorgängern deiner Klassen (welche TDatasets konsumieren) den Typen und das handling zu ändern?
Und wenn du schon dabei bist: Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

)

**tomaten**

Zitat von Robert_G:

Ist es nicht möglich einen Dekorator über ein System.Data.DataSet zu stülpen, der von einem "TDataSet" ableitet und somit die "Übersetzung" übernimmt?
Wäre es nicht außerdem möglich einfach in den Vorgängern deiner Klassen (welche TDatasets konsumieren) den Typen und das handling zu ändern?
Und wenn du schon dabei bist: Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

)

Naja viel akzeptieren .NET Klassen als DataSource ja nicht. Bei ADO.NET und connectionless DB wirds mir übel, wenn ich an den Overhead bei ein paar tausend SQL-Abfragen pro Sekunde denke. Vielleicht denke ich auch falsch, aber ich bin froh, dass dbExpress eine ständige Verbindung zur DB hält. Ich wollte auch eine Wrapper-Klasse bauen, damit ich nicht jeden .Eof, .Next, FieldByName usw. ersetzen muss, aber es muss doch auch einfacher gehen. Ich kann doch da nicht der Einzige mit diesem Problem sein!?

**Generalissimo**

Zitat von tomaten:

Wer will schon freiwillig diesen ADO-Kram benutzen?

Zitat von Bernhard Geyer:

Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

Was habt ihr alle immer nur gegen das DataSet von .Net Ich finde das übelst praktisch.
ADO.NET <> ADO das muss man auch erst verstehen. Es hat sich dabei einiges verändert.
Zumal .NET bzw. gerade ADO.NET nicht auf Client-Server-Szenarien, wie tomaten in seinem Projekt vorgeht, ausgerichtet ist.
In .Net 2.0 kommt noch ne "Binärkomprimierung" hinzu.

Das mit dem Dekorator ist ne gute Idee. Allerdings würde ich beim Umstieg auf das Verbindungslose Web (was ASP.NET definitv ist)
wirklich drüber nachdenken vom alten Client-Server-Prinzip zum N-Tier-Prinzip überzuwechseln. Wird dir in der Zukunft mehr Erfolg bringen.

Achso. Ganz vegessen. Vielleicht bringt dir der Link was:

Zitat von BDN:

Or, since we have the very cool VCL for .NET, we can simply not do any conversion of code whatsoever, and simply do it this way:

markieren

Delphi-Quellcode:

			Table1.First;

  while not Table1.EOF do begin

    ListBox1.Items.Add(Table1['NAME']);

    Table1.Next;

  end;

http://bdn.borland.com/article/0,1410,31996,00.html

**tomaten**

Zitat von Generalissimo:

Allerdings würde ich beim Umstieg auf das Verbindungslose Web (was ASP.NET definitv ist)
wirklich drüber nachdenken vom alten Client-Server-Prinzip zum N-Tier-Prinzip überzuwechseln. Wird dir in der Zukunft mehr Erfolg bringen.

Wo steht geschrieben, dass Web sei verbindunglos? Ich mache ausschliesslich Webanwendungen und die sind alles andere als verbindunglos und wahnsinnig schnell. Irgendwann muss ich nun mal aktuelle Daten lesen und schreiben (damit bin ich auch ohne ADO.NET sparsam, aber in der Summe kommt da immer noch reichlich zusammen)! Und wo sollen da also noch x Schichten hin? Man kann es echt übertreiben, wo nicht Not am Mann ist! Browser = UI, Webserver = Bussiness-Logik, DB-Layer, DB ...! Ist für meinen Geschmack ausreichend! Wir wollen die auch nicht weiter als über's Web "verteilen"! Da auch unsere DB auf Klassen basiert (also quasi keine festen Strukturen wie üblicherweise hat) ist schneller DB-Traffic das "A" und "O"! Dabei graut es mir vor den ständigen ADO.NET Verbindungsaufbauten!

**Bernhard Geyer**

Zitat von tomaten:

Naja viel akzeptieren .NET Klassen als DataSource ja nicht. Bei ADO.NET und connectionless DB wirds mir übel, wenn ich an den Overhead bei ein paar tausend SQL-Abfragen pro Sekunde denke.

Und wieso das? Du holst auch unter ADO.NET jeden Datensatz einzeln. Du verwendest jedoch keine Serverseitigen Curser mehr. Was übrigens auch von der Serverlast her seine Vorteile bietet (vor allem bei MS-SQL-Server, welche für jeden Serverseitigen Curser eine temporäre Tabelle füllen muss, da ja das Multi-Version-Konzept fehlt

Zitat von tomaten:

Vielleicht denke ich auch falsch, aber ich bin froh, dass dbExpress eine ständige Verbindung zur DB hält.

dbExpress ist ein ganz schlechtes Beispiel. Du mußt um die Datenmenge in beiden Richtungen durchlaufen zu können erst die Daten in ein TClientDataset kopieren. Und da bist du eigentlich schon wieder bei disconnected Datasets.

Disconnected heißt primär nicht das du nach jeder Abfrage die DB-Verbindung beendest (wird auch nicht bei ASP.NET gemacht. Da wird sie in den Connection-Pool gelegt), sondern das das Ergebnis deiner Abfrage keine DB-Verbindung mehr benötigt und z.B einfach auf einen anderen Rechner übertragen werden kann (N-Tier-Anwendungen) oder gespeichert werden kann.

Zitat von tomaten:

Ich wollte auch eine Wrapper-Klasse bauen, damit ich nicht jeden .Eof, .Next, FieldByName usw. ersetzen muss, aber es muss doch auch einfacher gehen. Ich kann doch da nicht der Einzige mit diesem Problem sein!?

Vielfach ist es kein großes Problem wenn die DB-Schnittstelle an wenigen Stellen konzentriert ist. So ist bei einem großen Projekt (1 Mio. Codezeilen) die DB-Schnittstelle (mit TDataset-Abhängikeiten) in wenigen 100 Zeilen in einer Unit konzentriert und alles andere läuft mit eigenen (disconnected) Datenklassen. Ein wenige wie ADO.NET, jedoch nicht so flexibel und mächtig.

@Generalissimo: Du hast mich fälschlicherweise zitiert.

**tomaten**

Zitat von Bernhard Geyer:

Und wieso das? Du holst auch unter ADO.NET jeden Datensatz einzeln. Du verwendest jedoch keine Serverseitigen Curser mehr. Was übrigens auch von der Serverlast her seine Vorteile bietet (vor allem bei MS-SQL-Server, welche für jeden Serverseitigen Curser eine temporäre Tabelle füllen muss, da ja das Multi-Version-Konzept fehlt

Naja, ich benutze zu 90% Oracle!

Zitat von Bernhard Geyer:

dbExpress ist ein ganz schlechtes Beispiel. Du mußt um die Datenmenge in beiden Richtungen durchlaufen zu können erst die Daten in ein TClientDataset kopieren. Und da bist du eigentlich schon wieder bei disconnected Datasets.

Mach ich fast niemals. Hauptsächlich Select's.

Zitat von Bernhard Geyer:

Disconnected heißt primär nicht das du nach jeder Abfrage die DB-Verbindung beendest (wird auch nicht bei ASP.NET gemacht. Da wird sie in den Connection-Pool gelegt), sondern das das Ergebnis deiner Abfrage keine DB-Verbindung mehr benötigt und z.B einfach auf einen anderen Rechner übertragen werden kann (N-Tier-Anwendungen) oder gespeichert werden kann.

Also Cursorless. Kann nicht gleich mal jemand zum Thema kommen? Endlich mal ne klare beruhigende Ausssage. Anders mach ich das bisher auch nicht!

Zitat von Bernhard Geyer:

Vielfach ist es kein großes Problem wenn die DB-Schnittstelle an wenigen Stellen konzentriert ist. So ist bei einem großen Projekt (1 Mio. Codezeilen) die DB-Schnittstelle (mit TDataset-Abhängikeiten) in wenigen 100 Zeilen in einer Unit konzentriert und alles andere läuft mit eigenen (disconnected) Datenklassen. Ein wenige wie ADO.NET, jedoch nicht so flexibel und mächtig.

So ähnlich ist das bei mir, aber ich habe einfach die Zeit nicht. Umstellung von Win32 "Express WebFramework" auf .NET "ASP.NET" wird auch schon genug Arbeit und es wird ständig weiterentwickelt! Also muss man das doch mal zur Diskussion bringen!

Ich suche doch einfach nur nach Möglichkeiten nicht alles auf einmal umzustellen! Dann kann ich ja gleich noch 450.000 Zeilen Code von Delphi in C# übersetzen!

**tomaten**

Zitat von Generalissimo:

Zitat von BDN:

Or, since we have the very cool VCL for .NET, we can simply not do any conversion of code whatsoever, and simply do it this way:

markieren

Delphi-Quellcode:

			Table1.First;

  while not Table1.EOF do begin

    ListBox1.Items.Add(Table1['NAME']);

    Table1.Next;

  end;

http://bdn.borland.com/article/0,1410,31996,00.html

Ist ja ganz spannend, wenn man die manuell durchlaufen will, ich rede aber von den "automatischen" also denen die einem Grid oder sonstigem als Source dienen!

Zitat von Generalissimo:

Zitat von Bernhard Geyer:

Muss es überhaupt ein .Net DataSet sein? (bei dem Ding vergates mir irgendwie immer....

Was habt ihr alle immer nur gegen das DataSet von .Net Ich finde das übelst praktisch.

Es speichert seinen Inhalt in Object, somit gibt es IMMER Boxing/Unboxing wenn du auf einen value type darin zugreifst -> pfui deivel!

Ich habe kein Problem mit Boxing durch das Binden an UI Elemente, ist ja nur UI. Aber wenn ich beim Verarbeiten, validieren, whatsoever ständig rumboxen müsste...

Es programmiert sich auch ekelhaft dagegen.

Ich persönlich setze lieber auf normale Klassen, die mit Hilfe von Metadaten und einem kleinen (selbst geschriebenen

) Enhancer in der Lage sind, selbstständig mit der DB zu "reden". DataSets wären doch IMHO viel zu umständlich und dieses DataAdapter-Gefriemel wäre mir auch zu ... friemelig.

Zitat von Generalissimo:

ADO.NET <> ADO das muss man auch erst verstehen. Es hat sich dabei einiges verändert.
Zumal .NET bzw. gerade ADO.NET nicht auf Client-Server-Szenarien, wie tomaten in seinem Projekt vorgeht, ausgerichtet ist.

Zitat von Generalissimo:

In .Net 2.0 kommt noch ne "Binärkomprimierung" hinzu.

Du kennst schon den BinaryFormatter?

Was du da als Vorteil von 2.0 ansiehst, benutze ich schon lange um meine Deltas zwischen den Tiers zu übertragen.

Was mich jetzt wirklich interessieren würde, wäre mehr, ob man Thomas' "DB Aware"-Klassen nicht anhand weniger Basisklassen, ganz unten in seinem Code, überzeugen könnte mit .Net Containern zu reden?