Wie macht Ihr den DataLayer?

19/12/2008 - 10:31 von Patrick Finger | Report spam
Hallo Group

Eine eher grundsàtzliche Frage..

Bisher setze ich in meinen asp.net-Projekten nhibernate mit "Session in
View-Pattern" als orm-Mapper ein. Für den Datenzugriff schreibe ich
jeweils eine Manager-Klasse, welche die verschiedenen Operationen (Get,
Update, Delete, etc) erbt und um Entitàt-spezifische Funktionen erweitert.
Dadurch wird der Business-Layer sauber vom Gui getrennt, kann separat
getestet und wiederverwendet werden.

Probleme gibts bei grösseren Projekten mit vielen, stark vernetzten
Datensàtzen. Trotz "Lazy-Loading" làdt Hibernate zu viele Daten nach
womit der Zugriff mit steigendem Datenvolumen merklich langsamer wird.

Hatte auch mal ein Projekt mit ado.net gemacht... War davon aber nicht
so begeistert da man unzàhlige Queries auwàndig in SQL schreiben muss.

Meine Trennung von Business & Gui möchte ich gerne beibehalten. Bin gar
kein Fan davon direkt im aspx queries zu definieren.
Die Vorteile eines ORM-Tools möchte ich auch beibehalten, finde es
extrem Praktisch wenn ich einfach meine Entitàten und deren Relationen
definieren kann um dann zur Laufzeit auf die vernetzen Entitàten
zugreifen kann.
zB, Pseudocode: Kunde.Auftraege[0].Lieferungen[0].Datum


Wie macht Ihr performante Datenzugriffe?
Verwendet Ihr auch ORM-Tools, welche?
Könnt Ihr andere Patterns als meines mit den Manager-Klassen empfehlen?

Danke und Gruss

Patrick
 

Lesen sie die antworten

#1 Thomas Bandt
19/12/2008 - 12:47 | Warnen spam
Hi,

Patrick Finger schrieb:
Bisher setze ich in meinen asp.net-Projekten nhibernate mit "Session in
View-Pattern" als orm-Mapper ein. Für den Datenzugriff schreibe ich
jeweils eine Manager-Klasse, welche die verschiedenen Operationen (Get,
Update, Delete, etc) erbt und um Entitàt-spezifische Funktionen erweitert.
Dadurch wird der Business-Layer sauber vom Gui getrennt, kann separat
getestet und wiederverwendet werden.



hört sich doch sehr gut an.

Probleme gibts bei grösseren Projekten mit vielen, stark vernetzten
Datensàtzen. Trotz "Lazy-Loading" làdt Hibernate zu viele Daten nach
womit der Zugriff mit steigendem Datenvolumen merklich langsamer wird.

Hatte auch mal ein Projekt mit ado.net gemacht... War davon aber nicht
so begeistert da man unzàhlige Queries auwàndig in SQL schreiben muss.



Habe bis vor Kurzem so gearbeitet (DataLayer mit Methoden die
jeweils via SqlCommand SPROCS abgefeuert haben - sehr aufwendig),
will das aber auch nicht mehr so machen müssen.

Meine Trennung von Business & Gui möchte ich gerne beibehalten. Bin gar
kein Fan davon direkt im aspx queries zu definieren.



Richtig so.

Die Vorteile eines ORM-Tools möchte ich auch beibehalten, finde es
extrem Praktisch wenn ich einfach meine Entitàten und deren Relationen
definieren kann um dann zur Laufzeit auf die vernetzen Entitàten
zugreifen kann.
zB, Pseudocode: Kunde.Auftraege[0].Lieferungen[0].Datum



Das mag schön sein, das Problem ist, dass du nicht weißt was
im Hintergrund exakt wann passiert, und du dann eben die
Probleme bekommst, die du jetzt augenscheinlich hast.

Was mir auch immer noch so gefàllt ist die Verdrahtung mit
den DataObjects - du bist letztendlich, wenn du in deiner App
mit den nHibernate-Objekten arbeitest, eigentlich auf Gedeih
und Verderb auf dieses Tool angewiesen. Ich abstrahiere da
lieber noch einmal mehr und nehme den einmaligen Mehraufwand,
im DataLayer vom Mapper nochmal auf eigene Objekte zu
mappen, in Kauf.

Wie macht Ihr performante Datenzugriffe?
Verwendet Ihr auch ORM-Tools, welche?
Könnt Ihr andere Patterns als meines mit den Manager-Klassen empfehlen?



Arbeite seit 2 Monaten nebenher an einem Dummy, bei dem ich auch
meine Arbeitsweise umgestellt habe. Ich nutze (mehr oder weniger
exakt) das RepositoryPattern.

public interface ICategoriesRepository
{
List<Categories> GetAllCategories();
Category GetCategoryByID(Guid id);
}

public class SqlCategoriesRepository : ICategoriesRepository
{
List<Categories> GetAllCategories()
{
}
Category GetCategoryByID(Guid id)
{
}
}

Aufruf erfolgt dann nur im ServiceLayer und ausschließlich
gegen das Interface. Aktuell wird in den Service-Klassen
dann SqlCategoriesRepository() usw. direkt instanziiert,
theoretisch làsst es sich dort aber mit Dependency Injection
ganz easy austauschen.

Den Datenzugriff selbst habe ich in dem Projekt mit LINQ to SQL
gemacht, weil ich damit selbst eine gewisse Abstraktion zur
DB bekomme und typsicher arbeiten kann, macht wirklich Spaß.
Leider setze ich damit schon auf ein sinkendes Schiff, weil MS
das Ganze bereits wieder absàgt und durch das ADO.NET Entity
Framework ersetzen will.

Ist mir aber völlig egal, denn wenn aus dem Dummy mal eine
ausgewachsene App werden wird, ersetze ich einfach nur die
direkten Datenzugriffe mit LINQ to SQL durch etwas anderes.

*Das* ist aber nur meine aktuelle Vorgehensweise, ich bin
stàndig selbst am lernen und weiterentwickeln, kann sein
dass ich in einem Jahr auch nur noch auf nHibernate setze ;)

Gruß, Thomas [MVP ASP/ASP.NET]
http://www.69grad.de - Beratung, Entwicklung
http://www.dotnetjob.de - .NET-Stellenmarkt
http://blog.thomasbandt.de - Thomas goes .NET

Ähnliche fragen