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.