Herangehensweise ADO/ADO.net/XML für Umsteiger

[Heinz Reiter]

Je mehr ich lese, des so verwirrter werde ich.
Also hat es keinen Sinn weiter zu lesen.

FRAGE: Wie sollte ein Datenzugriff in VS erfolgen?

BISHER habe ich meine Anwendungen mit Delphi + ADO
mit Access und SQL-Server2000 aufgebaut.
Jetzt sollen meine Programme ausgebaut und renoviert werden.
Schwerpunkte sind:
a) Wechsel zu VS2005
b) Anbindung Palm, Notbook, Internet

PROBLEM:
Die Buchautoren sind sich irgendwie nicht einig.
Manche schwören auf Objekte/Klassen/BusinessLayer,
manche auf XML ...
Aber irgendwie tauchen immer Probleme auf -
"XML ist zu langsam"...

Ich würde gerne die Daten aus der DB holen,
in Klassen bearbeiten bzw. die Kontrolle bekommen,
bearbeiten und abspeichern,
ohne auf die Unterstützung von VS zu verzichten.

Wie mache ich das am besten?

Ich benötige einen Tip, wo ich anfange und worauf ich mich konzentrieren soll.
Oder einen guten Buchtip, wo nicht die einzelnen Technologien nebeneinander gestellt werden,
sondern wo das praxisgerechte Zusammenspiel erläutert wird.

Ich hoffe, es ist klar geworden, worum es mir geht.

Gruß Heinz Reiter

[Martin Szugat]

Hallo!

Ja, leider behandeln die Bücher stets XML oder ADO.NET, obwohl doch beide so gut zusammenpassen. Ein Buch, welches beides behandelt, sich aber leider auf die Beta von .NET 2.0 bezieht, ist:

http://www.amazon.de/gp/product/0321247124/sr=8-1/qid=1155034953/ref=sr_1_1/302-6329045-8028817?ie=UTF8&s=gateway

Grundsätzlich gilt, zumindest ist das meine Meinung, für die Datenspeicherung und schnelle Abfrage gibt es keine Alternative zu einer Datenbank, sofern es sich um strukturierte (tabellenartige) Daten und nicht um (z.B. Word-)Dokumente handelt. XML eignet sich hingegen hervoragend für den Datenaustausch, sei es zwischen verschiedenen Anwendungen (Synchronisation, Mashup, Web Services, etc.) und/oder Anwendern (Import/Export). Zur Datenhaltung ist es nur bedingt geeignet, z.B. bei überschaubaren Daten, die keine schnelle Abfrage benötigen, z.B. Konfigurationsdateien.

Zum Glück bieten gerade ADO.NET und der SQL Server 2005 umfangreiche Möglichkeiten, relationale Daten als XML zu importieren als auch zu exportieren. Von daher: ADO.NET und XML.

Beste Grüße

Martin
www.aboutxml.d

[Heinz Reiter]

Das angesprochen Buch "Ado.Net and System XML v. 2.0. The Beta Version" habe ich schon gelesen.
Das ist ein Vertrter der XML-Fraktion - XML als Allerheilmittel.
Keine Rede davon, das XML- Datenzugriff um ein 10-faches langsamer sein soll (?).
Leider habe ich keine Zeit, um mich in alle Strategien einzuarbeiten und umfangreiche Tests durchzuführen

[Martin Szugat]

Kann ich jetzt (aus meiner Erinnerung) nicht bestätigen, dass die Autoren sich zur XML-Fraktion bekennen - eine strategische Empfehlung wird meines Wissens nach nicht gegeben, was allerdings ein Manko ist.

Zur Geschwindigkeit des XML-Datenzugriffes: Wie (fast) immer, hängen die Werte stark von dem ab, was man macht und wie man es macht. Es ist z.B. zu unterscheiden, ob man alle Daten lesen möchte oder gezielt nach bestimmten Datensätzen suchen möchte. Außerdem spielt es eine erhebliche Rolle, ob das XML-DOM oder XmlReader oder XPathDocument eingesetzt wird. Vom Einsatz des XML-DOMs ist abzuraten, wenn Performance eine Rolle spielt. XmlReader ist dagegen sehr flott. Hier spielt es keine Rolle mehr, ob es sich um eine Textdatei oder eine XML-Datei handelt.

Aber gerade, wenn man selektiv nur bestimmte Datensätze aus einer großen Datenmenge lesen möchte, kommt man eben nicht an einer Datenbank vorbei. Erstens, müssen die Daten nicht im Speicher gehalten werden bzw. stets aufs Neue eingelesen werden und zweitens hat man hier den (Geschwindigkeits-)Vorteil der Indizes.

Einen direkten Vergleich zwischen einem Datenbanksystem und XML halte ich für sinnlos. Das ist so als würde man eine Axt mit einem Hammer vergleichen: zwei unterschiedliche Werkzeuge für unterschiedliche Zwecke. DBs sind für die Datenhaltung, XML für den Datenaustausch. Klar, kann man das eine für das andere gebrauchen, so wie man eine Axt auch als Hammer verwenden kann, aber man würde es nur tun, wenn man keinen Hammer hätte

[Bernhard Geyer]

Um große Datenmenge zu Handhaben ist XML immer problematisch. Schon mal mehrere GB's als XML-Dateien versucht zu laden/speichern. Richtige SQL-Server haben der Größenordnung im GB-Bereich auf aktuellen Rechnern kein Problem.

Ach ja Palm: Willst du wirklich für dieses Sterbende Pferd noch irgendwas investieren. Ich würde darauf Tippen das in 1-2 Jahren kein neues Gerät mehr mit Palm-OS auf den Markt kommt

[Heinz Reiter]

Ja, Du hast Recht - Palm war nur eine Floskel.
Besser wäre gewesen "MobilGeräte" zu sagen, man weiß ja nicht was alles noch kommt

[Andreas Kosch]

Hallo,

>FRAGE: Wie sollte ein Datenzugriff in VS erfolgen?

Das hängt primär von der Architektur (Standalone, Client/Server, Three-Tier, Peer-to-Peer) sowie dem Datenvolumen ab. Heute, da mit 2 GB RAM bestückte Dual Core-Rechner im Low-Cost-Bereich auftauchen, verschiebt sich bei XML die Bewertung. Aber generell haben relationale Datenbanken noch die Nase vorn, zumal die aktuellen Versionen mit dem XML-Datentyp bei Bedarf eine Alternative lassen (Aber wann benötigt man schon eine Tabelle, in der jeder Datensatz eine unterschiedliche Anzahl von Spalten haben darf?) .

>Manche schwören auf Objekte/Klassen/BusinessLayer,...

Es ist beliebt, jedes Ding in einen bestimmten Schubkasten einzuordnen. Wenn das von Visual Studio 2005 generierte typisierte DataSet (inkl. TableAdapter) in eine separate Assembly (Class Library) ausgelagert wird, bildet diese Klassenverpackung der Datenbanktabellen einen Data Access Layer (DAL). Wenn in Visual Studio 2005 eine Component-Nachfolgerklasse angelegt wird, damit VS den Designer anzeigt, um dort nichtvisuelle Komponenten über den Properties-Editor konfigurieren zu können bzw. die Vorteile der VS-Wizards zu nutzen, hat man einen Businell Logic Layer (BLL). Wenn ein Entwickler die Bequemlichkeiten von Visual Studio 2005 ausnutzt, ohne dazu die Begriffe DAL und BLL zu verwenden, geht das aber auch in Ordnung :-)

Nur dann, wenn jemand propagiert, dass der Entwickler die DAL- und BLL-Klassen von Hand schreiben muss (also auf die Klassengeneratoren aus VS verzichten soll), wird es fragwürdig

[Heinz Reiter]

Wenn ich das richtig verstanden habe -
- ist Objekte/Klassen/BusinessLayer sinnvoll und ok
- soll ich die "Automatik" von VS2005 nutzen,
über das typisierte Dataset die Klassen anlegen zu lassen.

Wenn ich die Literatur richtig verstanden habe, dann überschreibt VS aber meine Anpassungen und Ergänzungen der Klassen! (?)

Die Situation:
- 1 Haupttabelle [t_H] mit wenigen Spalten, abhängig von
- vielen Neben/Lookup/Zuliefertabellen [dt_1,...,dt_150] mit z.B.: Auswertungen von Gesetzestexten (HOAI ...).

Aus den vom Benutzer eingetragenen Werten werden über die dt_X recht komplex wenige Werte [t_H] berechnet und eingetragen.
Also muß ich im Code die Werte sehr stark bearbeiten.

Ich denke, Klassen, die ich "im Griff" behalten kann wären wohl sinnvoll?

Wie kann ich das - am sinnvollsten - aufbauen in VS2005; oder ist ein persistence tool wie NHibernate besser

[Andreas Kosch]

Hallo,

>..dann überschreibt VS aber meine Anpassungen und Ergänzungen der Klassen!

nur bei .NET 1.1 (Visual Studio .NET 2003), aber nicht bei .NET 2.0. Visual Studio 2005 legt beim ersten Zugriff auf die Quelltextdatei die <b>partial class</b> in einer separaten Datei an, die alle Umstrukturierungen überlebt.
a) <i>DataSetXYZ.xsd</i> (von VS 2005 kontrolliert)
b) <i>DataSetXZY.Designer.cs</i> (von VS 2005 kontrolliert)
c) <i>DataSetXYZ.cs</i> (vom Entwickler kontrolliert)

Das folgende Beispiel demonstriert das Prinzip:

<div style="font-family: Courier New; font-size: 10pt; color: black; background: white; border-top: windowtext 1pt solid; padding-top: 0pt; border-left: windowtext 1pt solid; padding-left: 0pt; border-right: windowtext 1pt solid; padding-right: 0pt; border-bottom: windowtext 1pt solid; padding-bottom: 0pt;"><p style="margin: 0px;"><span style="color: blue;">namespace</span> NorthwindDataAccess</p><p style="margin: 0px;">{</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; <span style="color: blue;">public</span> <span style="color: blue;">partial</span> <span style="color: blue;">class</span> EmployeesDataSet : DataSet</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">public</span> <span style="color: blue;">partial</span> <span style="color: blue;">class</span> EmployeesDataTable : DataTable</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">public</span> <span style="color: blue;">override</span> <span style="color: blue;">void</span> BeginInit()</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">this</span>.ColumnChanging += ValidateColumn;</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">&nbsp;</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">void</span> ValidateColumn(<span style="color: blue;">object</span> sender, DataColumnChangeEventArgs e)</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">if</span> (e.Column.ColumnName == <span style="color: maroon;">"BirthDate"</span>)</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">if</span> ((<span style="color: teal;">DateTime</span>)e.ProposedValue &lt; <span style="color: teal;">DateTime</span>.Parse(<span style="color: maroon;">"1.1.1950"</span>))</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; {</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style="color: blue;">throw</span> <span style="color: blue;">new</span> <span style="color: teal;">ArgumentException</span>(<span style="color: maroon;">"Prüfen Sie bitte das eingetragene Datum!"</span>);</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">&nbsp;&nbsp;&nbsp; }</p><p style="margin: 0px;">}</p></div>

Da in ADO.NET 2.0 das typisierte DataSet viel umfangreicher ist als vorher (typisierter <b>DataSet</b>-Nachfolger; typisierter <b>DataTable</b>-Nachfolger; typisierte <b>DataRow</b>-Nachfolger; typisierte <b>RowChangeEvent</b>-Ereignisse; typisierter DataAdapter), stehen eine Unmenge vordefinierter Methoden, Eigenschaften und Ereignisse zur Verfügung. Außerdem besteht die Option, dass die so genannten DBDirect-Methoden als Ersatz für die universelle Update-Methode des DataAdapters ebenfalls automatisch geneneriert werden

[Heinz Reiter]

Super!
Das kommt davon, wenn man in älteren Büchern liest.

Das ist doch schon mal ein Ansatz, den es sich lohnt, zu verfolgen - oder nicht?

Danke
Heinz Reite