Datasets und Objektmodelle Wo sind sie geblieben...? E-Mail Marcel@Gnoth.net No. DS3, DC4, NA11

Zur Person Dipl. Inf. Marcel Gnoth, MCSD NTeam GmbH, Berlin www.gnoth.net Code und Powerpoint auf der Webseite NTeam GmbH, Berlin www.nteam.de IT – Infrastruktur, BI, Entwicklung Senior Consultant, Trainer, Programmierer Autor dotnet magazin und dotnetpro VB6, COM, Datenbanken Verteilte Informationssysteme Und .... .Net 

Agenda Teil 1 Teil 2 Einordnen der Datasets Einige praktische Betrachtungen

Das Dataset sucht seinen Platz Teil 1 Das Dataset sucht seinen Platz

Physische Architekturen Tier -> Schicht die gute alte Zeit ... Client / Server 3 – Tier und jetzt noch der Webserver Zugriff auf externe Systeme

Semantisch Architekturen Fat Clients Aufteilung in Dienste vertikaler Zugriff -> Layer Aufteilung in Komponenten, Kapselung von Funktionalität Aufteilung: GUI Objekte (Business Logic) Datenbank

Die Geschäfts Logik Objektmodell Dann kam MTS / COM+ Eigenschaften Methoden Dann kam MTS / COM+ statuslose Objekte keine Eigenschaften, nur Methoden

Was ist schlecht an Status... ... in der Mittelschicht ?? wenn viele Clients Bindung von Ressourcen auf dem Server zwischen den Methodenaufrufen  Threads Speicher Serverfarmen werden schwierig, Server muß Status des Client wieder finden

Vier Layer / drei Tier Trennung von Bearbeitung und Darstellung UserAgent in eigene Dll Objekte haben Status Komponenten: .Net EnterpriseServices oder Webservices möglichst kein Status, schlecht für Skalierbarkeit Tiers können auf dem selben Computer laufen

Modell / View / Controller altes Design Pattern Daten mit denen etwas gemacht wird passiv, überwiegend Eigenschaften Verschiedene Ansichten auf Daten (View) Winword (Normal, Seite, Gliederung) Powerpoint Controller tut etwas mit den Daten überwiegend Methoden kein Status

Realisierung des MVC-Pattern

Warum Controller aufgeteilt UserAgent besorgt Daten für Client, hat technischen Status Geschäftslogik Verarbeitet Daten und liefert Ergebnisse Kommunikation mit Drittsystemen Transaktionslogik Pooling von Ressourcen für viele Clients

Datenaustausch Anwender möchte Daten sehen (oben) Die Daten sind in der DB gespeichert (unten) Verarbeitung in der Mitte wie wandern die Daten?? zwischen Prozessen zwischen Computern zwischen verschiedenen Systemen Schnelligkeit Interoperabilität ......

Datenaustausch Kopie der Daten schicken (serialisieren) Menge von Objekten als Byte – Strom (Byte – Array) Transport über das Netz möglich Objektreferenzen prozeß- und computerübergreifend DCOM, CORBA, Remoting Achtung: jeder Zugriff ist teuer bei Methodenaufrufen müssen Parameter serialisiert werden (in, ref, out)

Datentransport früher ADODB Recordset (serialisierbar) war nur flache Ergebnismenge Objekte (serialisierbare), Interface implementieren! Baum möglich eigene Formate definieren Objekte Status in XML umwandeln und auf der Empfängerseite zurückwandeln Daten beim Methodenaufruf übergeben

Die Datasets kommen mehrere Ergebnismengen Relationen zwischen Tabellen (Kunde->Bestellung->Detail) können um eigene Elemente erweitert werden, erben sind das direkte Ergebnis der DB – Abfrage direktes Binden an GUI

Datasets Können Änderungen cachen Änderungen können direkt in DB geschrieben werden Auf Konflikte prüfen DataAdapter, bei mehr als einer Tabelle aufwendig Änderungen können rückgängig gemacht werden

Typisierte Datasets Erweiterung der Klasse Dataset für jede enthaltene Tabelle werden individuelle DataTable – Objekte und DataRow – Objekte generiert Compiler kann Typsicherheit prüfen werden generiert Typsicherheit wird nicht erzwungen unübersichtlich

In Memory Database Filter mit Where Klausel Sortieren Erzeugen eigener Views über mehrere Datatables

Warum noch Objektmodelle??? Aufbau der OOModelle aus Datareader, aus Dataset Overhead der Objektinstaziierung spielt keine Rolle Programmcode lesbarer und wartbarer Der GUI – und der Server Programmierer werden es Ihnen danken Aber mehr Aufwand bei Pflege des OO – Modells Aufwand und Nutzen sollten sich die Wage halten 

Recordsets und Datasets Nachteile kein echtes „semantisches“ Objektmodel nicht typisiert keine Methoden Vorteile Einfach zu erzeugen Änderungen in DB schreiben Können mit DBNull umgehen + / - keine Abstraktion, direkte Daten

Erfahrungen mit dem Dataset Mehrere Tabellen sind gut Aber oft speichern und möglichst Tabellenweise Eltern / Kind Änderungen sind komplizierter zu speichern (Insert / Delete) „dumme“ DataAdapter Nutzerführung Nach Laden aus DB DS um eigene Spalten und Tabellen ergänzen

Ein paar Ideen aus der Praxis Teil 2 Ein paar Ideen aus der Praxis

Beispielprojekt Spieldatenbank Drei Klassen und drei Collection – Klassen (Hashtable) Gefüllt über einen Datareader Ein Paket hat Paketschritte und Speicherungen als Eigenschaften Ein Dataset mit drei Datatables Gefüllt über drei Dataadapter Relationen und PK – Contraints Na? Wer ist schneller ???

DEMO

Serialisieren Für Übertragung der Daten wichtig 320.000 Zeilen Wie groß ist ein serialisiertes Dataset 52MB Objektmodell 29 MB Beim Serialisieren hätten sie das XML optimieren können Dim ms As IO.MemoryStream = New IO.MemoryStream Dim bf As BinaryFormatter = New BinaryFormatter bf.Serialize(ms, m_DS) lblDSSize.Text = ms.Length.ToString("#,#")

Das Dataset als Collection Erben von oder aggregieren eines Datasets Implementieren von Add, Remove Item Item instanziiert Objekte und gibt Referenzen heraus IEnumarable und IEnumerator evtl. IList ergänzen um Methoden Alles was das Herz begehrt 

Achtung Objektreferenzen Intern werden die Daten in DataRows gehalten Item gibt Objekte heraus Kopien ? Immer die gleiche Referenz ? Zugriff auf einzelne Elemente Verwaltung der „Herausgegebenen Elemente“ da bei Value „On Demand“ werden Objekte generiert

Beispiel

Daten in DataRow halten Normale Collection – Klasse Beim Füllen werden den Objekten ihre DataRows übergeben Intern wird der Objektzustand in einer DataRow gespeichert Über Property – Prozeduren wird auf die Eigenschaften zugegriffen Datarows sind mit DataTable verbunden Updates zur DB 

Beispiel

Schlussfolgerung Datasets sind eine In-Memory Datenbank, die MS uns mit COM+ versprochen hat Nicht mehr... ...und nicht weniger! Umfangreiche Möglichkeiten Filterung, Sortierung, Views Intressante Variante eines DataObjects!

Wann Updaten?? MS gibt uns eine InMemory DB komplexe Operationen können lokal ausgeführt werden Änderungen werden in einem „Rutsch“ gespeichert schont den Server (bei sehr vielen Anwendern)

Probleme mit der Nebenläufigkeit was wenn: viele Anwender gleichzeitig arbeiten komplexe Operationen auf Konsistenz zum DB Modell geprüft werden müssen Primärschlüssel benötigt werden Das Leben wird plötzlich sehr kompliziert... Fummlig 

Wann DS einsetzen wenn man wirklich den DB-Server entlasten muß (disconnected Ansatz) Außendienstmitarbeiter ?? interessante Datenstruktur für lokale Auswertungen kann sortieren, filtern,....

Klassisch OOModell komplexe Client Logik Eigene Objektmodelle komplexe Objekte, bei denen Sie eine Menge Methoden implementieren „wollen“ sehr effizient so oft speichern wie möglich erhöht die Konsistenz verringert die Entwicklerprobleme 

Fragen? Uff... Alles wird gut 