Dataset, Datatable oder bessere eigene Objekte + Management für Projekt?

[Manuel Wiersch]

Hallo,

ich überlege eine etwas größere Datenbankanwedung zu schreiben und dabei auf eine 2 bzw. 3-Schichten Architektur(Datebankverbindung und Zugriff, Geschäftsregeln und Logik, Darstellung) zu setzen (am Ende bleibt das ganze eine Anwendung). Als Datenbank möchte ich den Sql Server Express verwenden.

Mein erster Ansatz war eigene Basisklassen für die Speicherverwaltung zu schreiben, anschließend um Datenzugriffe und Geschäftsregeln erweitern und zuletzt das ganze über einen View-Architektur an die Steuerelemente zu binden. Mehrere Datensätze die z.B. in einem Grid angezeigt werden, sollen über eine DataTable an das Grid gebunden werden.

Das Programm soll neben der Eingabe der üblichen Kundendaten auch eine aktive Suche bieten (mit Eingabe eines Namens wird bereits im Datenstamm gesucht).

Nun scheint mich .Net mit einem Dataset bereits die benötigten Mechanismen zu liefern um performant eine mehrschichtige Anwendung zu realisieren. Hat jemand Erfahrung mit dem Dataset in mehrschichtigen Umgebungen oder setzt ihr lieber auf eigene Speicherverwaltung + Datenzugriff (natürlich automatisiert)?

MfG Manuel.

[Andreas Kosch]

Hallo,
ich setze generell in meinen dreischichtigen (WAN-)Anwendungen nur DataSets ein, wobei in den meisten Fällen jeweils ein typisisiertes DataSet genutzt wird. Mit dem .NET Framework 2.0 und dem neuen typisierten TableAdapter ist der Komfort innerhalb von Visual Studio 2005 an dieser Stelle nochmals gestiegen, so dass die typisierten DataSets den produktivsten Weg darstellen. Da der TableAdapter auf Wunsch auch die DBDirect-Methoden generiert, steht somit sogar ein automatisch generierten Data Access Layer (DAL) zur Verfügung, der an der Update-Methode des DataSets vorbei einzelne Datensätze (oder Werte) in die Datenbank schreiben kann.
Über die partiellen Klassen von .NET 2.0 lassen sich sowohl die typisierten DataSets als auch der typisierte TableAdapter erweitern, ohne dass eine Strukturänderung der Datenbank diese Erweiterungen in Gefahr bringt.

Der Vollständigkeit halber müssen auch die O/R-Mapper genannt werden. Wenn die Datenmenge relativ klein bleibt, die Belastung im Mehrbenutzerbetrieb nur gering ist und die Nebenwirkungen tolerierbar sind, ersparen die O/R-Mapper als andere Alternative das Schreiben von eigenen Klassen.

&#10

[Manuel Wiersch]

Hallo,

wie sieht es bei einem Dataset mit der Performance aus?
Ich lese immer dass ein Dataset sehr viel Overhead hat, was sich sicher auf die Performance der Anwendung auswirken wird.

MfG Manuel

[Andreas Kosch]

Hallo,
die saubere Trennung zwischen den Layern kostet nun einmal CPU-Zeit. Wenn es auf jede Millisekunde ankommt, muss das DataGridView in der Benutzeroberfläche direkt an einen DataReader gebunden werden (dies geht in .NET 2.0) - in diesem Fall gibt es keinen Klassen-Overhead, aber eine direkte Kopplung des Formulars (Benutzeroberfläche) zur Datenbank.

Wenn die Datenbankanbindung in einen Data Access Layer (DAL) ausgelagert werden soll, bleibt nur die Kapselung über Klassen übrig. Aber anstelle diese Klassen zeitaufwändig selbst zu schreiben, bevorzuge ich die von Visual Studio automatisch generierten Klassen des typisierten DataSets/TableAdapters :-)

>..Ich lese immer dass ein Dataset sehr viel Overhead hat.

In der Tat hatte die DataTable im .NET Framework 1.x eine Macke, die mit steigender Datensatzanzahl immer größer wurde. In .NET 2.0 wurde die DataTable-Klasse jedoch von Grund auf neu geschrieben, so dass in .NET 2.0 dieses Performance-Problem nicht mehr reproduzierbar ist. Außerdem lässt die DataSet-Klasse ein Abspecken zu:

a) Die Eigenschaft <b>RemotingFormat</b> erlaubt das binäre Serialisieren des DataSet-Inhalts (Wert <b>SerializationFormat.Binary</b>).

b) Die Eigenschaft <b>SchemaSerializationMode</B> verkleinert über den Wert <b>SchemaSerializationMode.ExcludeSchema</b> die zu transportierende Datenmenge drastisch, indem nur noch die reinen Daten, aber keine Metadaten (mit der Strukturbeschreibung) zwischen dem DAL und der Benutzeroberfläche übertragen werden.

[mirkom76]

Hallo,

ich persönlich tendieren zu einem O/R Mapper. Es ist unter .NET 2.0 zwar schön, dass man sich alles mit der Maus zusammen bauen kann. Doch was ist, wenn sich die Datenstruktur ändert, und weitere Felder hinzukommen. Aus meiner Erfahrung muss man dann alles neu zusammenstellen. Bei der Verwendung eines O/R Mappers braucht man ausschliesslich die entsprechende Spalte, die angezeigt werden soll zu erweitern. Hat man sogar die Spaltendarstellung so eingestellt, dass sie automatisch zusammengestellt werden, bedarf es keinerlei Anpassung.

Es ist doch schliesslich so, dass gerade anpassungen Zeit kosten und vor allem Bugs verursachen. Welche Applikation hat heutzutage keine Änderungen?

Bei Wikipedia gibt es neben der genauen Erklärung eine Liste von .NET O/R Mappern.
http://de.wikipedia.org/wiki/Object-Relational-Mapping

Grundsätzlich gilt allerdings, dass O/R Mapper immer langsamer sind als DataSets.

[Andreas Kosch]

Hallo,

es ist verständlich, dass sich jeder Entwickler für den Mittelpunkt der Welt hält, aber in vielen Fällen ist doch die Datenbankanwendung nur ein "Mittel zum Zweck". Die ORM-Begründung "Damit die Anwendung ein sauberes OOP-Design hat und es für den Entwickler einfacher wird" wird nicht bei jedem Kunden (Datenbankadministrator) auf Verständnis stoßen ;-)

Es gibt einige grundsätzliche Probleme zum Object/Relational Impedance Mismatch:

a) Gewissenskonflikte bei den Design-Zielen

In einer relationalen Datenbank steht die effiziente und universell auswertbare Speicherung von Informationen im Vordergrund. Bei einem OOP-Objektmodell geht es jedoch stattdessen vor allem darum, den Zustand einer Objektinstanz für den Entwickler möglichst bequem zu speichern. Es besteht daher die reale Gefahr, dass der Entwickler aus Eigennutz seine Bequemlichkeit höher bewertet und als Folge davon die universelle Verfügbarkeit der Daten in Mitleidenschaft gezogen wird.

b)Tier-Konflikte (Netzwerkzugriff)

Eine relationale Datenbank (SQL Server) speichert die Daten in der Regel auf einer separaten Maschine, die über das Netzwerk angesprochen wird (Client/Server- oder Three-Tier-Architektur). Ein OOP-Objektmodell unterstellt jedoch implizit, dass die Instanzen lokal erreichbar sind, da ansonsten bei den zahlreichen Aufrufen eine untolerierbare Wartezeit entsteht. Dieser Konflikt macht sich bei allen O/R-Mappern als so genanntes „N+1 Query Problem“ (alias „Eager Load vs. Lazy Load“) bemerkbar. Wenn zum Beispiel eine Instanz des Kunden-Objekts die Bestellungen dieses Kunden in der über eine Membervariable eingebetteten Kollektion Bestellungen speichert, stellt sich beim Datenzugriff die Frage, ob die Kollektion mit den Bestellungen bereits dann gefüllt werden muss, wenn die Kundeninstanz erzeugt wird? Konkret würde dies bedeuten, dass der O/R-Mapper von der Datenbank nicht nur die Feldwerte der Kundeneigenschaften aufrufen muss, sondern zusätzlich für jede Bestellung auch eine Bestellung-Instanz füllt und in der Bestellungen-Kollektion ablegt. Der Entwickler kann sich nur für das kleinere Übel entscheiden. Beim frühen Füllen (Eager Load) sind alle Master-/Detail-Daten sofort verfügbar, allerdings zu Lasten einer massiven Verschwendung von Datenbank- und Netzwerk-Ressourcen im Fall von großen Datenmengen. Beim verzögerten Füllen (Lazy Load) werden die Detail-Daten erst bei Bedarf (dem ersten Zugriff auf die Master-Eigenschaft) einzeln nachgeladen. Es kommt jedoch zum N+1 Query Problem, da jeder Zugriff auf jeden Master mit separaten Detail-Zugriffen beantwortet wird. Als Ergebnis muss der SQL Server eine hohe Zahl von einzelnen SELECT-Abfragen ausführen.

c) Konflikte beim Informationszugriff

Während eine relationale Datenbank die Beziehungen zwischen Tabellen aufgrund des Normalisierungsprozesses sauber strukturiert, basieren die OOP-Objektmodelle aufgrund der Zeiger-Verkopplung auf einem chaotischeren Ansatz, um das Ziel der Bequemlichkeit für den Entwickler zu erreichen. In einer relationalen Datenbank steht die effiziente und universell auswertbare Speicherung von Informationen im Vordergrund. Über SQL können die Daten über die Projektion und Selektion in frei wählbarer Gestalt abgerufen werden. Im Gegensatz dazu muss ein OOP-Objektmodell aufgrund der Zeiger-Beziehungen immer den kompletten Objekt-Graphen betrachten, um über die Zeiger-Werte die zusammenhängenden Daten zu ermitteln. Es sind nur die Auswertungen möglich, die im OOP-Objektmodell explizit vorgesehen wurden.

d) Fazit

Es hängt von den Umgebungsfaktoren ab, ob ein O/R-Mapper die richtige Wahl ist.

[maximus]

Nach zuweisung von

Dataset.SchemaSerializationMode = SchemaSerializationMode.ExcludeSchema

erhalte ich folgende exception:

SchemaSerializationMode property can be set only if it is overridden by derived DataSet
weiß wer, was das bedeutetd, bzw. wie man die richtigexcludiert ?

[Ralf Jansen]

Das Funktioniert nur bei typisiertes Datasets.

Einem untypisierten Dataset muß man immer das Schema mitgeben, woher soll auch sonst die Tabellenstruktur etc. im Datasets kommen.


PS. Mach demnächst besser ein neues Thema für ein neue Frage auf.

[maximus]

danke ralf