ADO Einsteigerbuch

[Uwe Stachel]

Kann mir jemand zum Einstieg in die ADO Programmierung mittels C# ein gutes Buch empfehlen? Die meisten Bücher die ich gesehen habe sind für ein Selbststudium wenig geeignet. Meistens ist es auch mehr eine Art Nachschlagewerk, ohne das der Leser mittels eigener Übungen an die Thematik geführt wird. Was ich auch oft gesehen habe ist, dass sich viele Bücher ausgiebig mit dem Produkt SQL Server beschäftigen und die Programmierung mit C# viel zu kurz kommt. Also hat jemand hier eine Empfehlung?

Vielen Dank!

[Andreas Kosch]

Hallo,

ich kann das Buch Programming Microsoft ADO.NET 2.0 Core Reference (ISBN 0-7356-2206-X) empfehlen, auch wenn es die genannten Anforderungen wohl kaum erfüllen wird.

Eine grundlegende Einführung in C# und ADO.NET für alle Einsatzfälle (von der klassischen Client/Server-Architektur bis hin zu dreischichtigen Anwendung bzw. Webanwendungen) wäre so umfangreich, dass es nicht mehr in ein Buch passen würde. Aus diesem Grund müssen sich Heute auch die Bücher spezialisieren. Aber selbst dann, wenn man nur das Teilgebiet ADO.NET herausgreift, kann nur eine sehr kompakte Darstellung (wie im Core Reference-Buch) einen halbwegs vollständigen Überblick geben.

[Uwe Stachel]

Hallo,

ich kann das Buch Programming Microsoft ADO.NET 2.0 Core Reference (ISBN 0-7356-2206-X) empfehlen, auch wenn es die genannten Anforderungen wohl kaum erfüllen wird.

Eine grundlegende Einführung in C# und ADO.NET für alle Einsatzfälle (von der klassischen Client/Server-Architektur bis hin zu dreischichtigen Anwendung bzw. Webanwendungen) wäre so umfangreich, dass es nicht mehr in ein Buch passen würde. Aus diesem Grund müssen sich Heute auch die Bücher spezialisieren. Aber selbst dann, wenn man nur das Teilgebiet ADO.NET herausgreift, kann nur eine sehr kompakte Darstellung (wie im Core Reference-Buch) einen halbwegs vollständigen Überblick geben.

Ja vielen Dank, dieses Buch hatte sich bei meinen Recherchen auch als eines der brauchbarsten herauskristallisiert.
Was mir spontan einfällt an Ihren Ausführungen ist, wenn ein Thema wie die Datenbankprogrammierung so umfangreich ist, ist es doch heute kaum mehr einem Entwickler zuzumuten, heute mal in der Datenbank-Entwicklung, morgen wieder in einem anderen Gebiet tätig zu sein (oder auch nur beispielsweise von SQL Server auf Oracle umzustellen). Was ich aber sehr oft erlebe ist, das gerade an IT'ler geradezu der Anspruch gestellt wird, diese "Flexibilität" an den Tag zu legen. Aber angesichts der Komplexität und des Umfangs, ist das nicht eine ziemlich unmögliche Anforderung?

[Thomas Sparenberg]

Hallo!

INFO: Ich glaube die deutsche Übersetzung des oben genannten Buches ist das Entwicklerbuch von Microsoft Press mit dem Titel ADO.NET 2.0.

mfg
Thomas

P.S.: Wir sind eben in einem Bereich tätig, der ständig im wandel ist. Ich bin ja schon froh das in .net 3.5 noch .net 2.0 drin ist.

[Bernhard Geyer]

Was mir spontan einfällt an Ihren Ausführungen ist, wenn ein Thema wie die Datenbankprogrammierung so umfangreich ist, ist es doch heute kaum mehr einem Entwickler zuzumuten, heute mal in der Datenbank-Entwicklung, morgen wieder in einem anderen Gebiet tätig zu sein (oder auch nur beispielsweise von SQL Server auf Oracle umzustellen).

Grundsätzlich stimm ich dir Zu das man nicht so einfach komplett andere SW-Themen von heute auf Morgen bearbeiten kann. Im Bereich Datenbanken solle ein Wechsel von einem zum anderen DBMS kein Problem darstellen indem schon die SW-Architektur ein DB-Neutralen Ansatz wählt um nicht hier die Falle des Anti-Patterns Vendor-Lockin zu stolpern. In 2007 ist sowas mit Techniken wie ECO oder NHypernate oder mit eigener Implementierung mittels Bridge-Pattern eine zu lösende Aufgabe.

Was ich aber sehr oft erlebe ist, das gerade an IT'ler geradezu der Anspruch gestellt wird, diese "Flexibilität" an den Tag zu legen. Aber angesichts der Komplexität und des Umfangs, ist das nicht eine ziemlich unmögliche Anforderung?

Man sollte als SW-Entwickler/Ingenieur auch genügend Rückrat besitzen um auch Forderung von Unmöglichkeiten abzulehnen. In meiner Firma wurde das schon ein paar mal gemacht und teilweise sind die Kunden nach der Schamzeit 3 Jahre (Abschreibung, Absägen von Verantwortlichen) auch wiedergekommen, dann mit realen Anforderungen :-)

[Uwe Stachel]

... Im Bereich Datenbanken solle ein Wechsel von einem zum anderen DBMS kein Problem darstellen indem schon die SW-Architektur ein DB-Neutralen Ansatz wählt um nicht hier die Falle des Anti-Patterns Vendor-Lockin zu stolpern...

Der DB neutrale Ansatz (gemeint ist nicht die Kapselung mittels Datalayers) wird, ähnlich der vielgerühmten Plattformunabhängigkeit, oft propagiert, aber macht dieser wirklich Sinn? Die Realität sieht doch meist so aus, das bereits viele Investitionen gerade in das Storage System getätigt wurden und auch meist andere Applikationen diese nutzen, so daß in der Praxis ein Austausch der Datenbank doch wohl eher selten der Fall ist, oder täusche ich mich hier? Wohlgemerkt, es geht hier nicht um den Einsatz von Patterns und dem ordentlichen Design des Datenbankzugriffs und der Transaktionen...

[Andreas Kosch]

Hallo,

wenn man sich die Entwicklung der letzten Jahre anschaut, nimmt die Funktionsbandbreite der SQL-Server abseits von ANSI-SQL ständig zu. Ein Datenbank-neutraler Ansatz unterliegt somit zwangsläufig dem Prinzip des kleinsten gemeinsamen Nenners, so dass die eigene Anwendung (bzw. die dort verwendeten Module) einen Teil der Funktionalität in allgemeingültiger Form selbst nachbauen muss, die in einem bestimmten SQL-Server bereits integriert vorliegt.

Genau so, wie wir uns als Entwickler spezialisieren müssen, wird das auch für die virtuelle Spezies der "Datenbankanwendungen" zutreffen. Dieser Spezialisierungsdruck trifft selbstverständlich für triviale bzw. kleine Datenbankanwendung nicht zu - denn dort wird die SQL-Datenbank "nur" als Ablageplatz von Informationen genutzt, die sich über ANSI-SQL verwalten lassen.

Auf den letzten BASTA's waren meine Night School-Sessions zum Thema "Aus Fehlern lernen" jeweils mit einigen abschreckenden Beispielen gefüttert, bei denen der Entwickler in C# (oder VB) etwas mühsam nachgebaut hat, was im Funktionsumfang des SQL-Servers bereits enthalten war. Allerdings kann der Entwickler diese "Schätze" nur dann heben, wenn er auch die Zeit hat, sich in die Leistungsfähigkeit und das Verhalten des betreffenden SQL-Servers auch in der notwendigen Tiefe einzuarbeiten. Auch dieser Aspekt spricht für die Spezialisierung...

[Bernhard Geyer]

Der DB neutrale Ansatz (gemeint ist nicht die Kapselung mittels Datalayers) wird, ähnlich der vielgerühmten Plattformunabhängigkeit, oft propagiert, aber macht dieser wirklich Sinn? Die Realität sieht doch meist so aus, das bereits viele Investitionen gerade in das Storage System getätigt wurden und auch meist andere Applikationen diese nutzen, so daß in der Praxis ein Austausch der Datenbank doch wohl eher selten der Fall ist, oder täusche ich mich hier?

Es geht mir eher darum das man als SW-Entwickler mehrer DB's unterstützt so das man nicht den Kunden ein bestimmtes DBMS auf Auge drücken muss bzw. wenn der Kunde unbedingt sein System haben will man sein Programm groß umbauen muß. Selbst Unterstützen wir mit unserer Anwendung 3 häufig im Einsatz befindliche DBMS und hatten bisher kein Problem damit das der Kunde eines davon nimmt. Hätten wir nur eines, so hätten wir mit Sicherheit ein paar Kunden weniger.

... Ein Datenbank-neutraler Ansatz unterliegt somit zwangsläufig dem Prinzip des kleinsten gemeinsamen Nenners, so dass die eigene Anwendung (bzw. die dort verwendeten Module) einen Teil der Funktionalität in allgemeingültiger Form selbst nachbauen muss, die in einem bestimmten SQL-Server bereits integriert vorliegt.

Um damit genau Schnurstracks ins Anti-Pattern Vendor-Lockin zu laufen. Man kann auch diverse spezialitäten Integrieren ohne den Vorteil der Neutralität aufzugeben. Mir wäre kein Feature bekannt das nicht in 1-2 Jahren die Konkurenz-DBMS ebenfalls haben. Und damit kann man es auch wieder kapseln.

Auf den letzten BASTA's waren meine Night School-Sessions zum Thema "Aus Fehlern lernen" jeweils mit einigen abschreckenden Beispielen gefüttert, bei denen der Entwickler in C# (oder VB) etwas mühsam nachgebaut hat, was im Funktionsumfang des SQL-Servers bereits enthalten war. Allerdings kann der Entwickler diese "Schätze" nur dann heben, wenn er auch die Zeit hat, sich in die Leistungsfähigkeit und das Verhalten des betreffenden SQL-Servers auch in der notwendigen Tiefe einzuarbeiten. Auch dieser Aspekt spricht für die Spezialisierung...

Könntest du ein paar Beispiele nennen? Ich vermute eher das viele Programmier aufgrund der generellen Unerfahrenheit mit DMBS vieles selbst machen.

[Bernhard Geyer]

Sind 2 Tage zu viel um auch 'ne andere DB zu unterstützen?
Post von Phoenix

[sgingter]

Dazu muss ich hier auch noch was sagen:

In der angesprochenen Anwendung wurden keine DB-spezifischen Funktionalitäten genutzt und auch in der DB waren keine Trigger etc. eingesetzt, die man auch noch hätte übersetzen müssen.

Wäre das der Fall gewesen hätte es sicher mehr Zeit gekostet, diese Sachen umzubauen.