Laden...

Intelligenz" der Datenzugriffsschicht

Erstellt von Quallo vor 16 Jahren Letzter Beitrag vor 16 Jahren 1.840 Views
Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren
Intelligenz" der Datenzugriffsschicht

Hallo,

ich habe eine Frage zur "Intelligenz" der Datenzugriffsschicht.
Generell muss ich sagen, dass die Datenzugriffsschicht mir eine List<T> zurückgibt.

Zwei Ansätze:
1.: Die Datenzugriffsschicht hat Methoden für Create, Read, Update, Delete und List, die mir Businessobjekte ohne Beziehungen zurückgeben.
In der Businesschicht würde ich dann wenn ich ein Attribut ändern will erst ein Read machen, die Eigenschaft ändern und dann ein Update. Beziehungen zwischen Objekten würde ich in der Businesschicht aufbauen(Beispiel: Nutzer hat Adresse...).

2.: Die Datenzugriffschicht hat intelligentere Methoden, beispielsweise eine SetStatus(ID) Methode, mit der ich den Status des Nutzers mit der Identität ID ändern kann. Man sollte dabei natürlich nicht absolut ins Detail gehen und für jedes Feld eine eigene Methode implementieren, sondern nur für Felder, wo es auch wirklich Geschäftsvorfälle für gibt.

Ich bevorzuge die zweite Variante, da sie deutlich mehr Performance und Rahmen für Optimierungen bietet (in diesem Projekt sehr wichtig). Natürlich ist der Implementierungsaufwand ungleich höher, was man aber durch ein geschicktes Framework wieder deutlich senken kann. Ich möchte mich allerdings nicht völlig auf den Holzweg begeben!

Bitte nicht in Diskussion ausarten lassen, ob ein OR-Mapper sinnvoller wäre oder ob man Datasets an die Businessschicht zurückgegeben sollte. Wir haben uns bewusst dagegen entschieden!

Grüße, Christoph

S
489 Beiträge seit 2007
vor 16 Jahren

Meine Frage passt zwar nicht zu Deinem Thread, aber wir wollen den OR-Mapper einsetzen, daher würde ich gerne wissen warum Ihr Euch dagegen entschieden habt. Danke!

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Zu geringe Flexibilität(Datenmodell sowie Businessobjekte müssen sich an ORM anpassen(besonders unschön, wenn man mit WCF auf Client und Server arbeitet und die Businessobjekte Attribute des ORM haben...)) und geringe Performance(teilweise arbeiten wir nicht nur mit optimierten SQl-Befehlen, sondern auch mit Optimizer Hints oder berechnen sogar Daten in temporären Tabellen vor, auf die wir dann per View zugreifen). Teilweise wurde haufenweise Code genriert oder man musste bei kleinen Änderugen immer wieder mit Assistenten arbeiten...

Für kleinere Sachen ist es sicherlich schöner als die per Assistent generierten Monolithen, bei performancekritischen Programmen wird es schon schlechter...

Grüße, Christoph

S
489 Beiträge seit 2007
vor 16 Jahren

Ok Danke! Mal sehen wie sich das bei uns entwickelt ...

476 Beiträge seit 2004
vor 16 Jahren

hallo Quallo,

ich würde für Ansatz 1 voten. Die Datenzugriffsschicht sollte meiner Meinung nach genau das machen wofür sie betitelt wird, den Datenzugriff regeln. Änderungen an einzelnen Daten sollten nur von den Business-Komponenten angestossen und ausgeführt werden. Ich selber nutze als Datencontainer DataTable-Objekte und übergebe sie um Änderungen zu übertragen an die Datenzugriffsschicht. Die Intelligenz der Datenzugriffsschicht begrenzt sich auf das automatische Erkennen der Datensätze die neu, geändert oder gelöscht wurden und überträgt diese Änderungen auf die Datenbank.

-yellow

Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).

Mein Blog: Yellow's Blog auf sqlgut.de

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Die Änderungen an den Daten werden auch in Modell 2 nur von der Businessschicht vorgenommen.
Es ist ja die Businessschicht, die beispielsweise die Methode SetStatus(ID) aufruft.
Es wird also alles von der Businessschicht gesteuert und die Datenzugriffsschicht ruft nicht eigenmächtig solche Funktionen auf.

Sind die DataTable eigentlich unabhängig von den Datentypen der Datenbank?
Ich habe beispielsweise GUIDs in Oracle als raw(16), im Prinzip ein Bytearray, abgebildet. Die DataTable müssten also völlig unabhängig von der Datenbank arbeiten, damit sie auch wirklich als Schnittstelle zwischen der Businessschicht und einem austauschbaren Datenlayer liegen können.

Grüße, Christoph

Q
Quallo Themenstarter:in
992 Beiträge seit 2005
vor 16 Jahren

Sorry für das hochschieben!

Bin aber inzwischen auch an Aussagen zu den DataTables/DataSets interessiert. Könnte ich mal einen Testfall zu aufsetzen.

Grüße, Christoph

476 Beiträge seit 2004
vor 16 Jahren

hallo Quallo,

natürlich wird auch in Modell2 die Änderung durch die Businessschicht ausgelöst, jedoch müsste dann die Datenzugriffsschicht über die Daten bescheid wissen. Und hier ist für mich der springende Punkt. Die Datenzugriffsschicht soll mir die Kommunikation mit der Datenbank erleichtern, aber keinesfalls in irgendeiner Form die Nutzdaten ändern.

Zu deiner Frage, ja, die Datentypen einer DataTable sind von der Datenbank unabhängig.

Eine Datenzugriffsschicht wie ich sie meine, ist beispielsweise im Thread Providerunabhänige Datenzugriffskomponente von Rainbird zu sehen. Natürlich enthält eine DataTable keine Contracts... diese könntest du aber mit Hilfe von typisierten DataSets erhalten. Hier hat sich in .NET Framework 2.0 einiges getan und es lohnt sich diese noch mal unter die Lupe zu nehmen. Du könntest somit typsicher Arbeiten und dennoch im Hintergrund die angenehmen Seiten von ADO.NET nutzen.

-yellow

Selbst ein Weg von tausend Meilen beginnt mit einem Schritt (chinesisches Sprichwort).

Mein Blog: Yellow's Blog auf sqlgut.de