AHA!-Erlebnis wirft weitere Fragen auf bzgl. DataTable und Co.

02/06/2008 - 17:33 von Anton Reinthaler | Report spam
Hi, NG

Im zuge meiner Frage hier am 31.05.08 und der Mithilfe von Peter Götz und
Frank Dzaebel probierte ich ein wenig mit SQL-Commands herum. Ein
Update-Command, das ich dann zu Testzwecken irgendwo mitten im Code von
Form1_Load platzierte, wurde auch sofort beim Starten des Programms
ausgeführt, und die Änderungen konnte ich augenblicklich in der DB
bewundern. Und das ohne DataTable, ohne DataAdapter, ohne DataView und auch
ohne CurrencyManager. Das war mein AHA!-Erlebnis.
Ich dachte bis jetzt, dass es in VB2005 ohne diese Objekte keine
Manipulation an der DB gàbe. Jedes Buch und auch alle Codeschnipsel, die ich
mir bisher angeschaut habe, verwenden diese Objekte.

Meine Frage jetzt:
Wenn ich beginne, alle Datenbankmanipulationen ohne diese erwàhnten Objekte
zu schreiben, habe ich dann im weiteren Verlauf des Programmcodes mit
Nachteilen zu rechnen?
Anders 'rum:
Wozu brauche ich diese komplexen Objekte, wenn es auch anders geht? Was kann
ich ohne die nicht realisieren? Oder was wird dann unverhàltnismàßig
schwieriger?

Wen es interessiert, hier der Code:


Grüße
Toni
 

Lesen sie die antworten

#1 Frank Dzaebel
02/06/2008 - 21:47 | Warnen spam
Hallo Anton,

Im zuge meiner Frage hier am 31.05.08 und der Mithilfe von Peter Götz und
Frank Dzaebel probierte ich ein wenig mit SQL-Commands herum. [...]
Und das ohne DataTable, ohne DataAdapter, ohne DataView und auch ohne
CurrencyManager.



Brauchst Du allerdings in der Mehrzahl der DB-Szenarien nicht
über zusàtzliche, eigene, manuelle, fehleranfàllige SQL-Kommandos
zu implementieren.

In vielen Fàllen kannst Du Abfragen sogar *ohne* eigenen
Code zu schreiben, implementieren!
Vielleicht ist das ja Dein nàchstes AHA-Erlebnis ;-)



Jedes Buch und auch alle Codeschnipsel, die ich mir bisher angeschaut
habe, verwenden diese Objekte.



Nicht durchgehend, es sind fast immer auch Beispiele
für eigene SqlCommand's da.




Wenn ich beginne, alle Datenbankmanipulationen ohne diese
erwàhnten Objekte zu schreiben, habe ich dann im weiteren Verlauf des
Programmcodes mit Nachteilen zu rechnen?



Ja, aber vielleicht (selten) auch mit Vorteilen.
Wenn man die Kommandos manuell zusammensetzt,
sind die ~normal fehleranfàlliger. Meistens musst Du
zusàtzlichen Aufwand treiben müssen, um wenigsten etwas
Typsicherheit hineinzubekommen.

Die moderne Programmierung ist eher schon bei
LINQ. Da hast Du schon Typsicherheit in den Abfragen
und ebenso automatische Performanz-Optimierung.

[LINQ]
http://dzaebel.net/LINQ.htm

Manuelle SqlCommands können in einigen wenigen
Szenarien die Performanz noch mehr steigern.
Die Implementation geht normal viel schneller mit
automatisch generierten SQL.



Wozu brauche ich diese komplexen Objekte, wenn es auch anders geht?



Vergleichbar mit: Wozu brauche ich ein Auto, wenn ich
den Weg auch selber gehen kann? (ich bin allerdings
begeisterter Radfahrer ;-)




Was kann ich ohne die nicht realisieren?



Etwa wie: Was kann ich ohne Auto nicht realisieren.
Als Beispiel, Du kannst sicher soetwas wie aus dem
Datenquellenfenster eine Tabelle in die Form ziehen
und dann das Programm einfach starten nicht in
der Zeit fertigstellen, wie es .NET für Dich "for free"
macht - noch dazu ohne die gàngigen Fehler, die
man halt so als Mensch da gerne macht.

Eins noch!
Wenn Du unsaubere Strukturen wie etwa Tabellen-
Spalten die eigentlich semantisch ID Charakter haben,
und dann aber doch nicht als PK definierst o.à., hat man
es unter .NET leicht schwerer mit der Automatik und den
vorgefertigten Data-Klassen.
Der richtige Weg ist da, das Unglück an der *Wurzel*
(der sauberen DB-Backend-Struktur) zu packen und nicht
durch manuelle Herumstrickereien irgendwelche Workarounds
herzustellen (ich sags lieber unverblümt)

In dem Augenblick, wo Du sauber im DB-Backend arbeitest,
helfen die Automatiken ungemein.


ciao Frank
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET

Ähnliche fragen