DB-Layer Architektur-Frage

16/07/2009 - 12:16 von Alexander Mueller | Report spam
Hallo

ich habe eine generelle Frage dazu, wie man am besten die
Datenbank-Schicht in einer klassischen .NET 2.0-Anwendung
mit Frontend und Backend und ein bisschen Business-Logik dazwischen
anlegt.

Umfeld: .NET 2.0, ADO.NET (kein EF, kein LinQ-To-SQL, kein 3rd-party
ORM)

Problem 1)
Es werden viele SPs aufgerufen, deren Ergebnis dann meist als DataSource
für Combos oder DataGridViews dienen.
Soll man für jeden verwendete SP eine Methode im DAL definieren, oder
besser eine generische DAL-Methode wie

DataTable QuerySP (string spName, params object[] args);

verwenden?

Die generische Variante finde ich eigentlich sympatischer, aber dann
müsste die View-Schicht die SP-Namen kennen.
Das soll sie ja nicht nach Prinzipien wie MVC oder MVP, nach denen
Sicht und Datenzugriff ja weitestgehendst von einander zu trennen
sind und die View-Schicht wohl nicht mal "wissen" darf, was eine
Datenbank ist...
Wie geht dass dann eigentlich mit dem DataBinding, wer bindet
die Datenquellen in MVP an die Controls, wenn die Sicht DB-unaware sein
soll?

Problem 2)
Abstraktion der verwendeten DB-Systeme.
Ist eine best-practice Frage.
Wenn ich aus Sicht- oder Logik-Schicht heraus eine SP aufrufe, die ein
paar Parameter erhàlt, wie macht man das am besten mit der Typisierung
und Benennung der Parameter?
Man müsste in einer generischen Methode wie QuerySP (s.o.) doch
ein params-Array übergeben, das erst Parameter-Namen als string, dann
den Wert mit seinem .NET übergibt.
In der SP müsste man das dann zu einem Command-Objekt mit Parameters
umwandeln und dabei auf DB-Spezifika bezüglich Type-Mapping
(.NET <-> SQL) achten. Das kann im Einzel-Fall krachen, wenn der
.NET-Typ nicht mit dem SQL-Typ match (z.B man hat ein .NET-Int, das ein
MySQL-sbyte werden soll, der Type-Mapper aber korrekt im MySQL-Int
wandelt).

Also der Kern der Frage ist, wie und wo ruft man, um modernen
Architektur-Prinzipien zu genügen, die DB-Queries auf - und wie
handelt man am geschicktesten die Parameter-Übergabe, -Typisierung und
-Benennung, wenn man unterschiedlich DB-Zielsysteme bedienen will?

Alle Hinweise willkommen,

MfG,
Alex
 

Lesen sie die antworten

#1 Peter Fleischer
16/07/2009 - 22:39 | Warnen spam
"Alexander Mueller" schrieb im Newsbeitrag
news:4a5efde9$0$32681$

ich habe eine generelle Frage dazu, wie man am besten die
Datenbank-Schicht in einer klassischen .NET 2.0-Anwendung
mit Frontend und Backend und ein bisschen Business-Logik dazwischen
anlegt.

Umfeld: .NET 2.0, ADO.NET (kein EF, kein LinQ-To-SQL, kein 3rd-party
ORM)



Hi Alexander,
logisch, da es im FW 2.0 kein LinQ gibt :-)

Problem 1)
Es werden viele SPs aufgerufen, deren Ergebnis dann meist als DataSource
für Combos oder DataGridViews dienen.
Soll man für jeden verwendete SP eine Methode im DAL definieren, oder
besser eine generische DAL-Methode wie

DataTable QuerySP (string spName, params object[] args);

verwenden?



Wenn schon, dann typsicher mit <T>, damit typisierte DataSets zurückgegeben
werden.

Die generische Variante finde ich eigentlich sympatischer, aber dann
müsste die View-Schicht die SP-Namen kennen.



Du kannst doch eine öffentliche Aufzàhlung nutzen.

Das soll sie ja nicht nach Prinzipien wie MVC oder MVP, nach denen
Sicht und Datenzugriff ja weitestgehendst von einander zu trennen
sind und die View-Schicht wohl nicht mal "wissen" darf, was eine
Datenbank ist...



Aber wissen, was sie benötigt, muss die UI schon. Im Sinne eines Interfaces
muss vereinbart werden, was bereitgestellt wird und was deshalb auch nur
aufgerufen werden kann.

Wie geht dass dann eigentlich mit dem DataBinding, wer bindet
die Datenquellen in MVP an die Controls, wenn die Sicht DB-unaware sein
soll?



Wenn du typgerecht arbeitest, kannst du auch mit voforantierten Grids
arbeiten.

Problem 2)
Abstraktion der verwendeten DB-Systeme.
Ist eine best-practice Frage.
Wenn ich aus Sicht- oder Logik-Schicht heraus eine SP aufrufe, die ein
paar Parameter erhàlt, wie macht man das am besten mit der Typisierung
und Benennung der Parameter?
Man müsste in einer generischen Methode wie QuerySP (s.o.) doch
ein params-Array übergeben, das erst Parameter-Namen als string, dann
den Wert mit seinem .NET übergibt.
In der SP müsste man das dann zu einem Command-Objekt mit Parameters
umwandeln und dabei auf DB-Spezifika bezüglich Type-Mapping
(.NET <-> SQL) achten. Das kann im Einzel-Fall krachen, wenn der
.NET-Typ nicht mit dem SQL-Typ match (z.B man hat ein .NET-Int, das ein
MySQL-sbyte werden soll, der Type-Mapper aber korrekt im MySQL-Int
wandelt).

Also der Kern der Frage ist, wie und wo ruft man, um modernen
Architektur-Prinzipien zu genügen, die DB-Queries auf - und wie
handelt man am geschicktesten die Parameter-Übergabe, -Typisierung und
-Benennung, wenn man unterschiedlich DB-Zielsysteme bedienen will?



Die DB-Queries ruft man in der DAL auf, egal, wie das Interface zur BL
aussieht.

Viele Grüsse
Peter

Ähnliche fragen