Applikation vorbereiten auf unterschiedliche Datenbank-Anbindungen

31/10/2009 - 21:29 von Michael Erlinger | Report spam
Hallo

ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
Jahren àndern wird, und dann soll diese Applikation mit einem SQL-
Server zusammenarbeiten.

Frage an die Profis hier: wie würdet Ihr eine solche Applikation
beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
der gleichen Datenbank-Struktur weiter zu verwenden.

Danke schon mal für Infos dazu
Schönen Gruß
Michael
 

Lesen sie die antworten

#1 Christoph Basedau
01/11/2009 - 04:07 | Warnen spam
Michael Erlinger schrieb:

ich soll eine C#-Applikation schreiben, die vorerst einmal auf eine
MySQL-Datenbank zugreiffen soll; was sich aber in einem bis zwei
Jahren àndern wird, und dann soll diese Applikation mit einem SQL-
Server zusammenarbeiten.

Frage an die Profis hier: wie würdet Ihr eine solche Applikation
beginnen, um nach der Datenbank-Umstellung möglichst wenig (oder gar
keinen) Programmier-Aufwand zu haben - die gleiche Applikation mit
der gleichen Datenbank-Struktur weiter zu verwenden.



Ist relativ unwahrscheinlich, dass man gar keinen Aufwand mehr hat.
Ebenso unwahrscheinlich ist, dass sich die DB-Schemata auf's Haar
gleichen. I.d.R gibt es da ein paar Feinheiten, z.B. beim
Datentyp-Mapping. MySQL hat z.B. afaics kein wirkliches bool
bzw bildet das intern als irgendein speziellen mini-int-Typ ab,
der in ADO.NET als sbyte gemappt wird.
MS-SQL unterstützt aber schon bool und .NET mappt das auch wie
erwartet und da fàngt es dann schon an...


Es empfiehlt sich natürlich die Connection- und andere -Parameter
in config-files auszulagern, dann bleibst Du auf dieser Ebene
schon mal flexibel.

Die Standard-Herangehensweise bzgl Klassenlayout sieht oft wie folgt
aus:

1. Traditionelle Herangehensweise (ADO.NET)
Zwei Datenzugriffsklasse, die jeweils als Intefaces abstrahiert
werden und für jedes RDBMS eine Implementation erfahren.
- Eine für grundlegende Datenzugriffe wie Connection aufbauen, SPs
ausführen und Daten zurückgeben bzw manipulieren, Transaktionskontexte
etc.

- Eine weitere, das eigentliche DAL, für die konkreten
Anwendungsspezifischen DB-Zugriffe kapselt und ausführt und die
intern die erstere verwendet. Wenn Du es richtig und gut machst, musst
Du diese Klasse nur einmal implementieren, weil alle DB-Spezifika
bereits von Klasse 1 abgefangen werden.

- DB-seitig möglichst alle Zugriffe über Stored-Procs
abfrühstücken, selbst trivialste SELECT *'s, so dass möglichst kein
SQL im Code vorkommt und außerdem alle Parameter typisierbar sind.
Benamsung von SPs und allen DB-Objekten möglichst ASCII,
unexotisch und nach nachvollziehbarem, übertragbarem Schema.
SP-Innereien eher schlicht halten im Hinblick auf Portierbarkeit.


Um trendy zu sein und im Windschatten des aktuellen Hypes und
auf der weiten See der Buzzwords zu segeln, kann man es mit
Object Relationalem Mapping versuchen:
Kapsle alle Datenbankzugriffe mit Hilfe eines ORM-Tools wie ADO-Entities
NHibernate oder Genome. Wirf SQL über Bord und lerne stattdessen HQL
oder eSQL und wie man Mapping-Dateien editiert, konzentriere dich
ansonsten auf OO und achte Performanceaspekte gering - sonst hast Du mit
ORM nicht immer Freude ;-) )

Gruß
Christoph

Ähnliche fragen