Unterschiedliche Datenquellen. Wie vorgehen?

[FredlFesl]

Hallo,

Ich habe eine dot.net / C# - Frage

Ich muss Daten von unterschiedlichen Quellen laden, z.B. einer Datei, Shared Memory, TCP, SQL-Datenbank. Dabei lese ich immer genau einen Record.
Für SQL wäre das also sowas wie ein "SELECT FIRST 1 <Felder> FROM <Tabelle> WHERE UniqueKey = :UniqueKey"
Bei TCP würde man die Daten irgendwie von einem Client abrufen (Query / Response - Mechanismus)
Bei Shared Memory liegen die Daten für den UniqueKey schon im Speicher
Bei einer Datei würde ich die Zeile filtern, die den UniqueKey enthält
...
Die Daten sollen nach dem Einlesen homogen weiterverarbeitet werden. Ich dachte da an eine Datatable.

Meine Frage lautet: Wie soll ich die unterschiedlichen Datenquellen implementieren? Soll ich für jede Datenquelle einen IDataReader bauen? Oder gibt es eine bessere Möglichkeit?

Für jeden Denkanstoß wäre ich dankbar. Die Implementierung ist nicht das Problem.

[WM_CLOSE]

Du könntest verschiedene Klasen definieren, die alle ein Interface implementieren, das z-B.So aussieht:

Delphi-Quellcode:

type
IDatenzugriff=interface
function LeseDatensatz(UniqueKey:String);
end;

type
TTCPDatenZugriff=class(IDatenzugriff)
public
  function LeseDatensatz(UniqueKey:String)
end;

implementation
function TTCPDatenZugriff.LeseDatensatz(UniqueKey:String)
begin
  //Hole Datensatz
end;

procedure VerwendeDatenzugriff();
var
 Datenzugriff:IDatenzugriff;
 Datensatz:TDatensatz;
begin
  if Zugriffsmethode=TCP then
  begin
    Datenzugriff=TTCPDatenZugriff.Create;
  end;

//...  

  Datensatz:= Datenzugriff.LeseDatensatz('UniqueKey');

//...

end;

end;

Ich hab jetzt kein Delphi zum ausprobieren, aber so ungefähr

[FredlFesl]

Hi,

Es geht um Dot.Net. Klar, so könnte man das machen. Aber ich möchte die Lösung so gestalten, das sie nahtlos in das Dot.Net DataProvider / Databinding - Konzept passt, sodaß man mit der richtigen Implementierung gleich eine ganze Reihe weiterer Aufgaben erschlägt.

Beispielsweise würde ich in Delphi versuchen, ein TDataset-Derivate zu erzeugen, damit ich alle datensensitiven Steuerelemente verwenden kann.

[omata]

Zitat von FredlFesl:

Es geht um Dot.Net.

Wo stand das? Der einzige (indirekte) Hinweis, war "IDataReader".

Oder bin ich blind, und das stand wirklich konkret in deiner Frage.

Edit: Ahhh, ok. NET-Sprachen war das Ober-Thema. Sorry.

[FredlFesl]

Nee, nee. Hast schon Recht. Hätte ich in einem DELPHI-Forum nochmals hinschreiben sollen.

[Phoenix]

Du wirst Zugriff auf SharedMem und TCP nicht in das DataProvider-Konzept zwängen können.

Ich würde tatsächlich wie WM_Close vorgeschlagen hat ein Interface definieren, welches den Datenzugriff kapselt.

Genauso würde ich, wenn es Sinn macht, lediglich ein Interface für die eigentlichen Daten definieren.

In .NET kannst Du Databinding ja auch ohne weiteres gegen beliebige Objekte (oder eben Interfaces) definieren, und genau hiervon würde ich gebrauch machen. Dann brauchst Du Dich auch nicht mit dem DataSet rumschlagen. Ausser dass es langsam und nicht threadsafe ist und damit ausschliesslich Probleme beschert ist es nämlich nicht wirklich zu was gut.

[FredlFesl]

Ah. Stimmt ja. Ich bin ja unter Dot.Net überhaupt nicht auf TDataset bzw. den Pendant angwiesen. Na dann mach ich das doch einfach so.

Danke!