No. DS3, DC4, NA11 E-Mail [email protected] Datasets und Objektmodelle Wo sind sie geblieben...?

No. DS3, DC4, NA11E-Mail [email protected]

Datasets und Objektmodelle

Wo sind sie geblieben...?

Marcel Gnoth, www.gnoth.net

Zur PersonDipl. Inf. Marcel Gnoth, MCSD

www.gnoth.net Code und Powerpoint auf der Webseite

NTeam GmbH, Berlinwww.nteam.de IT – Infrastruktur, BI, Entwicklung

Senior Consultant, Trainer, Programmierer

Autor dotnet magazin und dotnetproVB6, COM, DatenbankenVerteilte InformationssystemeUnd ....

.Net

http://www.gnoth.net/

http://www.nteam.de/


Agenda

Teil 1 Einordnen der Datasets

Teil 2Einige praktische Betrachtungen

Teil 1

Das Dataset sucht seinen Platz


Physische ArchitekturenTier -> Schichtdie gute alte Zeit ...Client / Server3 – Tier und jetzt noch der

WebserverZugriff auf externe

Systeme

Arbeitsstation Arbeitsstation

Server

Daten


Daten


Webserver

Daten

Geschäftskomponenten


Semantisch Architekturen

Fat ClientsAufteilung in Dienste vertikaler Zugriff -> LayerAufteilung in Komponenten,

Kapselung von FunktionalitätAufteilung:

GUIObjekte (Business Logic)Datenbank

COM

Windows Form

COM

COM

Daten


Die Geschäfts Logik

Objektmodell EigenschaftenMethoden

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 ThreadsSpeicherServerfarmen werden schwierig, Server

muß Status des Client wieder finden


Vier Layer / drei TierTrennung von Bearbeitung

und DarstellungUserAgent in eigene DllObjekte haben Status

Komponenten: .Net EnterpriseServices oder Webservicesmöglichst kein Status,

schlecht für SkalierbarkeitTiers können auf dem selben

Computer laufen

WebserviceCOM+

Data

User Agent

Windows Form


Modell / View / Controller

altes Design PatternDaten mit denen etwas gemacht wird

passiv, überwiegend EigenschaftenVerschiedene Ansichten auf Daten

(View)Winword (Normal, Seite, Gliederung)Powerpoint

Controllertut etwas mit den Daten überwiegend Methodenkein Status


Realisierung des MVC-Pattern

Business Logic

Data

Windows Form

User Agent

View

Modell

Contr.


Warum Controller aufgeteiltUserAgent besorgt Daten für Client, hat

technischen StatusGeschäftslogik

Verarbeitet Daten und liefert ErgebnisseKommunikation mit DrittsystemenTransaktionslogikPooling 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 Prozessenzwischen Computernzwischen verschiedenen SystemenSchnelligkeitInteroperabilitä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übergreifendDCOM, CORBA, RemotingAchtung: jeder Zugriff ist teuerbei 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 definierenObjekte Status in XML umwandeln und auf

der Empfängerseite zurückwandelnDaten beim Methodenaufruf übergeben


Die Datasets kommen

mehrere ErgebnismengenRelationen zwischen Tabellen

(Kunde->Bestellung->Detail)können um eigene Elemente erweitert

werden, erbensind das direkte Ergebnis der DB –

Abfrage direktes Binden an GUI


Datasets

Können Änderungen cachenÄnderungen können direkt in DB

geschrieben werdenAuf Konflikte prüfen

DataAdapter, bei mehr als einer Tabelle aufwendig

Änderungen können rückgängig gemacht werden


Typisierte Datasets

Erweiterung der Klasse Datasetfür jede enthaltene Tabelle werden

individuelle DataTable – Objekte und DataRow – Objekte generiert

Compiler kann Typsicherheit prüfenwerden generiertTypsicherheit wird nicht erzwungenunübersichtlich


In Memory DatabaseFilter mit Where KlauselSortierenErzeugen eigener Views über mehrere

Datatables


Warum noch Objektmodelle???Aufbau der OOModelle

aus Datareader, aus DatasetOverhead der Objektinstaziierung spielt

keine RolleProgrammcode lesbarer und wartbarerDer GUI – und der Server

Programmierer werden es Ihnen dankenAber mehr Aufwand bei Pflege des OO –

Modells Aufwand und Nutzen sollten sich die

Wage halten


Recordsets und DatasetsNachteile

kein echtes „semantisches“ Objektmodel

nicht typisiertkeine Methoden

VorteileEinfach zu erzeugenÄnderungen in DB schreibenKönnen mit DBNull umgehen

+ / -keine Abstraktion, direkte Daten


Erfahrungen mit dem DatasetMehrere Tabellen sind gutAber oft speichern und möglichst

TabellenweiseEltern / Kind Änderungen sind komplizierter

zu speichern (Insert / Delete)„dumme“ DataAdapter

NutzerführungNach Laden aus DB DS um eigene

Spalten und Tabellen ergänzen

Teil 2

Ein paar Ideen aus der Praxis


Beispielprojekt

SpieldatenbankDrei Klassen und drei

Collection – Klassen (Hashtable)Gefüllt über einen DatareaderEin Paket hat Paketschritte und

Speicherungen als EigenschaftenEin Dataset mit drei Datatables

Gefüllt über drei DataadapterRelationen und PK – Contraints

Na? Wer ist schneller ???

Pakete

Paketschritte Speicherungen


DEMO


SerialisierenFür Übertragung der Daten wichtig320.000 ZeilenWie groß ist ein serialisiertes

Dataset 52MBObjektmodell 29 MB

Beim Serialisieren hätten sie das XML optimieren könnenDim 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 CollectionErben von oder aggregieren eines

DatasetsImplementieren von

Add, RemoveItem

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 herausKopien ?Immer die gleiche Referenz ?

Zugriff auf einzelne ElementeVerwaltung 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 übergebenIntern wird der Objektzustand in einer

DataRow gespeichertÜber Property – Prozeduren wird auf die

Eigenschaften zugegriffenDatarows 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, ViewsIntressante Variante eines

DataObjects!


Wann Updaten??

MS gibt uns eine InMemory DBkomplexe Operationen können

lokal ausgeführt werdenÄnderungen werden in einem

„Rutsch“ gespeichertschont den Server(bei sehr vielen Anwendern)


Probleme mit der Nebenläufigkeitwas wenn:

viele Anwender gleichzeitig arbeitenkomplexe Operationen auf Konsistenz

zum DB Modell geprüft werden müssen

Primärschlüssel benötigt werdenDas 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

Auswertungenkann sortieren, filtern,....


Klassisch OOModell

komplexe Client LogikEigene Objektmodelle

komplexe Objekte, bei denen Sie eine Menge Methoden implementieren „wollen“

sehr effizientso oft speichern wie möglich

erhöht die Konsistenzverringert die Entwicklerprobleme


Fragen?

Uff...Uff...

Alles wird gut

No. DS3, DC4, NA11 E-Mail [email protected] Datasets und Objektmodelle Wo sind sie geblieben...?

Documents

Transcript of No. DS3, DC4, NA11 E-Mail [email protected] Datasets und Objektmodelle Wo sind sie geblieben...?