Datasets und Objektmodelle

Präsentation zum Thema: "Datasets und Objektmodelle"—  Präsentation transkript:

1 Datasets und Objektmodelle
Wo sind sie geblieben...? No. DS3, DC4, NA11

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

3 Agenda Teil 1 Teil 2 Einordnen der Datasets
Einige praktische Betrachtungen

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

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

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

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

8 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

9 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

10 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

11 Realisierung des MVC-Pattern

12 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

13 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 ......

14 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)

15 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

16 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

17 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

18 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

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

20 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 

21 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

22 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

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

24 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 ???

25 DEMO

26 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("#,#")

27 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 

28 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

29 Beispiel

30 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 

31 Beispiel

32 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!

33 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)

34 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 

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

36 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 

37 Fragen? Uff... Alles wird gut 