Zitat von
Jürgen Thomas:
@Elvis,
ist das vielleicht auch eine vereinfachte Lösung anstelle von Bridge-Patterns, die Bernhard Geyer empfiehlt? Das würde meine eigenen Entscheidungen (siehe die Dir bekannten Diskussionen) beeinflussen. Jürgen
Naja ganz vorbeikommen wirst du daran nicht.
Aber ein guter Anfang wäre zum Beispiel wenn du die ProviderFactories in eine eigene Verpacken würdest und diese um einen "richtigen" CommandBuilder erweiterst.
Dem kannst du dann sagen was du woher abfragen willst und wie verknüpft und gefiltert wird.
Der
Sql Server mit seinem ekelhaften TSQL ist inkompatibel zu so ziemlich allem was auf dem Name RDMS laut "hier" ruft.
Dummerweise haben die Jungs vom FirebirdProvider dieses widerliche @ und die widerliche Angewohnheit übernommen, dass man das widerliche @
immer dem Parameter voranstellen muss (also auch bei ParameterName
).
Ich fürchte MS plant mal wieder einen neuen "Standard" zu schaffen, sozusagen das was wir schon hatten und gut lief nur jetzt in hässlich und friemelig (wenn's
einfach läuft ist's ja auch langweilig
).
Oki, zurück von meinem Depri über die Hirnies vom TSQL-Team...
Überlege dir wie der CommandBuilder aussehen muss und vor allem was er für dich können muss. (Selektierte Spalten?, Filter?, Joins?, Standardfunktionen á la SubStr, Trim,... übersetzen?)
Danach kannst du einfach ein Interface baust, dass praktisch die Member von DbProviderFactory hat, nur um ein CreateSqlBuilder erweitert.
Jetzt musst du im Endeffekt für jedes
DBMS nur noch von deren DbFactory ableiten, die neue Methode implementieren und deiner Ableitung dein Interface verpassen.
Für den Rest reicht ein highjacking des bestehenden
ADO.Net DbProvider-Systems:
Du baust dir also eine neue statische Klasse, die als Factory für dein Interface dient.
Die muss praktisch alles nur an die bestehende DbProviderFactory durchreichen.
Deine eigenen Factories brauchen natürlich einen eigenen InvariantName, da würde es schon reichen ein "JT." vor den bestehenden zu setzen.
Ooodeeer du schaust dir nHibernate an, was dir Bernhard und ich schon mehrfach empfohlen haben.
Erst wenn du nHibernate als untauglich ansehen solltest, würde ich Arbeit in eine eigne Implementierung investieren. Und auch da, wie oben beschreiben, möglichst viel von dem bestehenden System aus
ADO.Net 2.0 wiederverwenden.