Late binding von Assemblys vorher bekannt machen, wie?

[mcGeorge]

Hallo NG,
mir ist einfach keine andere Überschrift eingefallen zu meiner Frage.

Also, ich habe in meinem Programm den Teil für die Datenbank in eine separate DLL ausgelagert. Diese DLL-Assembly lade ich beim Programmstart per Late binding hoch. Ich habe z.B. verschiedene DB.DLL für verschiedene Datenbanktypen (MSSQL,MYSQL,...) erstellt. Die lade ich bei jeder Installation für die jeweilige DB hoch. Die öffentlichen Eigenschaften, Methoden und Ereignisse in dieser Klasse sind natürlich identisch.

Nun zu meiner Frage:
In meiner Main-Application in der ich die DLL mit Late binding lade, muss ich immer "blind" Programmieren, da dort ja die DB.DLL nicht bekannt ist. Mann kann doch sicherlich eine Schnittstellen-/Klassenbeschreibung erstellen, mit der ich das Objekt in der MainApp. erstellen kann, so dass ich beim Programmieren bereits die vorhandenen Methoden zb. vorgeblendet bekomme.
Auch um einfach Programmierfehler zu vermeiden.

Wenn das geht, kann mir jemand ein kleines Beispiel zur Verfügung stellen?
Vielen Dank im Voraus.
Georg

[Christian Marquardt]

Würde da an Interfaces denken

http://msdn.microsoft.com/en-us/library/28e2e18x.aspx

[mcGeorge]

Hallo Christian, vielen Dank für diesen Tipp.

Verstehe ich das oder mache ich das richtig, wenn ich in einem separaten Module für jede DLL die ich per Late binding lade eine Interface-Beschreibung hinterlege. Mit dieser Interface-Beschreibung die Objektvariable erstelle und danach mit Late binding initialisiere.
Ist das richtig so.

Georg

[Christian Marquardt]

Würde ich nicht so sehen. Allerdings kenne ich auch die genauen Anforderungen nicht.

M.E. sollte es EIN Interface geben. Dieses kapselt die Bedingungen/Anforderungen für alle Datenbanken. Also

ConnectString
Passwort
User
Path To DB
o.a


Also bindet deine konkrete Anwendung das Interface ein. Welche DB "dahinter" steht ist egal, die DB kann mittels Interface connectet werden.

[Ralf Jansen]

Wenn du für jede DLL ein eigenes Interface hast wie programmierst du dann dagegen? Es bliebe das gleiche Problem das du jetzt hast.
Es ist so wie Christian sagt. Es sollte nur ein eindeutiges Interface geben gegen das der allgemeine Teil deiner Anwendung arbeitet und eben die Gemeinsamkeiten aller Implementierungen darstellt. Du kannst dann dynamisch zur Laufzeit eine konkrete Implementierung laden und über das Interface verwenden.

[mcGeorge]

Sorry, ich habe wieder ein Gedankensprung gemacht. Natürlich nur ein Interface für alle Datenbank-Assemblys. Das hatte ich auch so verstanden.
Ich habe in meinem Programm noch weitere "Plugins" (ca. 10 Stück) neben der DB.DLL, die erst zur Laufzeit gebunden werden. Das meinte ich mit "jeder DLL".

Gibt es eine einfache Möglichkeit aus einer fertigen Klasse automatisch die Schnittstellenbeschreibung zu erstellen? Irgend ein Tool?

Georg

[Ralf Jansen]

Wenn das aufgrund des Aufwands nötig ist würde ich mal behaupten die Klasse macht zuviel
Ein Interface extrahieren gehört zu den vorhanden Refactorings in Visual Studio (zumindest in C# Shortcut wäre CTRL+R,I).

[fanderlf]

Ich würde mich auch fragen ob ich diese Aufteilung nach dll überhaupt brauche. Vermutlich würde ich alles zusammen in einen Datenzugriffslayer packen und das dann per Konfiguration steuern, sofern Dein Produkt das zulässt.