Laden...

Data Access Layer in C#

Erstellt von sindibad vor 11 Jahren Letzter Beitrag vor 11 Jahren 3.290 Views
S
sindibad Themenstarter:in
110 Beiträge seit 2012
vor 11 Jahren
Data Access Layer in C#

verwendetes Datenbanksystem: Oracle und MS Sql

Hallo,
ich lese in einer C#-Applikation Daten aus einer MS sql Datenbank und schreibe sie mit andere Daten zusammen in einer Oracle Datenbank. nach dem Datentransfer lösche ich anschließend die Daten aus der ms sql Datenbank.
Ich habe nach einen guten Design gesucht für die Datenbank Schicht weil für beide Dtenbanken gleiche Befehelen brauche wie open , close, excecutenoquery, command, connection...
Ich habe die Data Access Layer wie im Beispiel
Implementing a Data Access Layer in C#
realisiert. finde nicht schlecht weil es Datenbank unabhängig ist und setzt interface und factory pattern.
was meint ihr dazu? wie würdet es designen?
mein Ziel ist die Design-Pattern zu erlernen und besser nutzen und mein Analyse und Design verbessern

2.187 Beiträge seit 2005
vor 11 Jahren

Hallo sindibad,

für den Datenbankzugriff verwende ich immer einen Objekt-Relationalen Mapper. Dies ist nicht der einzige Weg aber ich finde es empfehlenswert da es so viel einfacher ist objektorientierte Technicken (Patterns, usw.) anzuwenden und deren Vorteile zu nutzen.

NHibernate und EntetyFramework sind bekannte ORMs, es gibt aber auch viele weitere (und auch viele die sich nur so nennen).
Ich empfehle dier einen bestehenden ORM zu wählen und sich mit einem Tutorial einzuarbeiten.

Gruß
Juy Juka

F
10.010 Beiträge seit 2004
vor 11 Jahren

Für Massendaten sind ORMapper nicht der ideale weg, da sie unnötige materialisierungen erzeugen und damit die Arbeit meist unnötig verlangsamen.

@sindibad:
Während die Idee als solche schon mal gut ist, ist deine Wahl eher schlecht.
Sobald man in einer Factory mehr als ein Switch/Case sieht ist irgendwas schiefgelaufen.
Auch ist das eher die Herangehensweise von FW 1.1, denn seit FW 2.0 haben wir die ProviderFactory bereits verfügbar,. sieht man auch an dem Gebrauch von IDbConnection statt den Generell besseren DbConnection (usw ) Interfaces/Klassen.
http://www.c-sharpcorner.com/UploadFile/amit_agrl/ProviderFactory08052005030042AM/ProviderFactory.aspx
http://www.codeproject.com/Articles/55890/Don-t-hard-code-your-DataProviders
Erklären wie man das besser machen kann.

Auf Codeprojekt gab es auch mal einen Artikel der beschreibt wie man da auch an sowas wie ParameterChar und Co kommt, den finde ich aber nicht auf die schnelle.

2.298 Beiträge seit 2010
vor 11 Jahren

Hallo sindibad,

Grundlegend ist es schonmal ein guter weg (wenn du ohne OR-Mapper oder ähnlichem arbeitest) eine DB Schicht ähnlich der in dem von dir verlinkten Artikel verwendest.

Einziges was mich an dem Artikel bisher immer gestört hat (ja ich hab den auch schon gefunden) ist, das einfach zu viel gemacht wird, was nicht notwendig ist.

Als ich darauf aufbauend meinen DAL geschrieben habe, habe ich auf vieles verzichtet, im Grunde kann man das alles in einer Klasse abhandeln, und kommt damit auch nur auf c.a. 500 Zeilen was ich für eine Klasse völlig in Ordnung finde.

Ich hatte das so gelöst, das ich Connectionstring und Providername (den vollen Namen z.B. System.Data.SqlClient) im Konstruktor übergebe.

Im Constructor erstell ich dann meine Connection mittels der DbConnectionFactories in dem ich den Providernamen übergebe.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |