Allgemeiner Datenbankzugriff unter .NET

[Alexander]

Hallo,
ich muss das Thema noch mal hervorholen. Ich habe noch 2 Probleme bzw. Fragen.
So folgenden Code nutze ich:

Delphi-Quellcode:

class function TSQLHelper.getDataAdapter(aArt: string): IDbDataAdapter;
begin
  if (aArt = 'MySQL') then
     result := MySqlDataAdapter.Create()
  else if (aArt = 'Firebird') then
     result :=  nil// FbConnection.Create(aConStr)
  else if (aArt = 'SQL-Server') then
     result := SqlDataAdapter.Create()
  else if (aArt = 'Access') then
     result := OdbcDataAdapter.Create()    // Wie geht's bei Access?
  else if (aArt = 'Datenbank über ODBC') then
     result := OdbcDataAdapter.Create();
  if (result = nil) then
    Exception.Create('Ungültige Datenbankart');
end;

class procedure TSQLHelper.getDataSet(var Res : DataSet; sql, ConStr, aArt : String);
var
  cmd : IDbCommand;
  con : IDbConnection;
  dataAdapter : IDbDataAdapter;
  DSet : DataSet;
begin
  con := getConnection(ConStr, aArt);
  cmd := con.CreateCommand();
  cmd.CommandText := sql;
  dataAdapter := getDataAdapter(aArt);
  dataAdapter.SelectCommand := cmd;

  dataAdapter.Fill(Res);
end;

Die Methode getConnection ist eigentlich wie getDAtaAdapter aufgebaut und poste ich der Übersichtlichkeit halber mal nicht.
Momentan teste ich nur mit ODBC, auch das dynamische Laden habe ich noch nicht integriert.
Das Dataset Res, das der Methode getDataSet übergeben wird, wird quasi gefüllt und ist mit dem DataGrid verbunden.
Doch wie kann ich die Daten in eine bestimmte Table des DataSets speichern?
Außerdem wäre es interessant, wie ich dann genau die DataSEt.Table im DataGrid anzeigen kann. Es erscheint ja normalerweise eine Auswahl aller Tables, bei der man sich erst eine aussuchen kann.

[Alexander]

Mal ein kleines dezentes *push*

[Jürgen Thomas]

Zitat von Alexander:

Doch wie kann ich die Daten in eine bestimmte Table des DataSets speichern?

Indem Du direkt die Tabelle angibst:

Delphi-Quellcode:

dataAdapter.Fill(Res, 'Kunden');
//  oder
dataAdapter.Fill(Res, tblKunden);

Zitat von Alexander:

Außerdem wäre es interessant, wie ich dann genau die DataSEt.Table im DataGrid anzeigen kann.

Ebenfalls, indem Du die Table zur Anzeige festlegst, z.B.:
dataGrid1.SetDataBinding(myDataSet, 'Kunden'); Für den Fall, dass etwas noch nicht erledigt sein sollte. Gruß Jürgen

[Alexander]

Hallo,
vielen Dank für deine Antwort ! Doch das hat sich schon erledigt gehabt .

Leider habe ich wohl vergessen, dies hier auch zu schreiben.

[Elvis]

Ich habe mir eigentlich nicht getraut dich hier zu deprimieren und den Weg zu zeigen, der in .Net 2.0 möglich wäre.
Dort kann man über die DbProviderFactories eine Factory nach Namen laden und sich natürlich alle registrierten Factories ausgeben lassen.

Selbst wenn dein DataProvider keine Factory besitzt lässt sich die mit ca. 50-60 Zeilen selbst schreiben (die Methoden überschreiben, die du bei deinem DBMS brauchst).
Du musst sie auch nicht im System regisrtieren, das .Net Konfigsystem schaut ja zuerst in deine App.config. Es reicht also dort deine Factory einzutragen.
Hier mal etwas pseudo code:

Delphi-Quellcode:

var factory := DbProviderFactories.GetFactory(factoryName);

using connection := factory.CreateConnection() do
using command    := connection.CreateCommand() do
begin
  with bldr := factory.CreateConnectionStringBuilder() do
  begin
     bldr['user id']     := deineUserId;
     bldr['password']    := deinPasswort;
     bldr['data source'] := deineDataSource;
     bldr['database']    := deineDatabase;
     connection.ConnectionString := bldr.ConnectionString;
  end;

  command.CommandText := 'SELECT X FROM Y WHERE Z = :Z';
  with prm := command.CreateParameter() do
  begin
    prm.ParameterName := 'Z';
    prm.Value := deinWert;
    command.Parameters.Add(prm);
  end;

  using da := factory.createDataAdpater() do
  begin
    da.SelectCommand := command;
    da.Fill(deineDatatable);
  end;
end;

Zusammen mit System.Transactions ist das ziemlich mächtig.

[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

[Elvis]

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.

[Jürgen Thomas]

Ach Elvis,

bitte versteht mich doch nicht falsch: Ich hätte nichts dagegen, mich mit nHibernate zu befassen. Ich will/muss mich jetzt mit einem DBMS befassen, möchte mir aber die Wege offen halten, später weitere DBMS einzubeziehen. Deshalb sollte ich von Anfang an flexibel bleiben.

Dafür suche ich jetzt den geeigneten Einstieg - siehe [dp]Interbase, MS-SQL oder... Was ist für mich am besten?[/dp]. Jürgen

[Elvis]

nHibernate kann, je nach DB Design, auch für ein einzelnes DBMS praktischer sein als das ganze Command-Gerödel.

[Alexander]

Uff. Das sieht ja richtig schick aus .
Gerade auch der ConnectionStringBuilder ist ja heftig .

Das würde mir echt viel Arbeit abnehmen...

Nachtrag: Den Builder kann man nicht zufällig irgendwie auch für .NET 1.1 bekommen, oder? Kann man nicht eine .NET 2.0 DLL erzeugen und diese irgendwie in Delphi.NET einbinden?