verwendetes Datenbanksystem: <egal>
Hallo Leute
ich bekomme aus einer DLL (auf die ich keinen Einfluss habe) beim Laden aus den DB's eine DataTable zurück. Auch beim Speichern erwartet die DLL eine DataTable. Nun möchte ich aber mit typisierten DataSets weiterarbeiten. Derzeit löse ich den Umstieg wie folgt:
// laden
DS_xxx.yyyDataTable dtzzz = new DS_xxx.yyyDataTable();
dtzzz.Merge(DB.Get_Data());
dtzzz.AcceptChanges();
// speichern
DataTable dt = new DataTable(dtzzz.TableName);
dt.Merge(dtzzz.GetChanges(), true);
return (DB.Save_Data(dt));
DS_xxx sind dabei die DataSets, und yyyDataTable die darin enthaltenen Tabellen. Kann man das ganze irgendwie (über Generics und Extensions o.ä.) so umschreiben, das ich nurmehr folgendes schreiben muss:
DS_xxx.yyyDataTable dtzzz = new DS_xxx.yyyDataTable();
dtzzz.???(DB.Get_Data());
// bzw.
DB.Save_Data(dtzzz.???);
Mit .Net3.5 und seinen Möglichkeiten bin ich leider noch nicht so vertraut. Vielleicht gibt es ja einen Trick, wie ich die Umwandlung einfach gestalten kann.
mfG
Thomas
Hallo Thomas
Sieht schlecht aus. Klemm dir am besten eine Bridge zwischen die "DB" und deine DataSets welche die Umwandlung zentral übernimmt.
Grüße
Flo
Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+
Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.
Hallo Flo
schade. Das mit der Bridge hab ich mir auch schon überlegt. Nachdem ich jetzt aber eine Anwendung mit 3 Accessdatenbanken und insgesamt 31 Tabellen umschreiben darf (von Delphi auf C# mit SQL-Server) wären das 62 Routinen. Ich hatte halt gehofft, das dies einfacher ginge.
P.S. ginge das ganze eventuell mit einem anderen O/R-Mapper (EF...) einfacher?
Grüße
Thomas
Hallo Thomas
Ich weiß nicht ob es einen O/R Mapper gibt mit dem du mehrere Datenbanken unter einen Hut bringen kannst - EF kann's jedenfalls nicht.
Es gibt natürlich architektonische Ansätze welche es ermöglichen mehrere Datenbanken unter einem Data Access Layer zu verstecken, der Aufwand lohnt sich aber meistens erst bei wirklich großen Business Layern welche auch mehrere Anwendungen bedienen sollen.
Wenn's nicht ganz so groß ist, würde ich die einzelnen Datenquellen über Bridges in das DataSet einbinden. Das ist zwar nicht ganz so schick, aber eventuell pragmatisch.
Grüße
Flo
Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+
Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.
Hallo Flo
das mit den drei Datenbanken müsste eigentlich egal sein. Beim Holen der Daten gebe ich die Datenbank mit an und bekomme dann eine DataTable zurück. Woher die Daten komme weiß mein Programm gar nicht, das wird ja in der DLL am Server gemacht (das ganze ist eine Client/Server-Anwendung). Ich habe mir eben überlegt, das ich für jede Datenbank ein typisiertes Dataset mit den Tabellen erstelle. Das hätte dann den Vorteil, das ich am Client eben nicht über Rows[x]["Name"] auf die Daten zugreifen muss.
Ich denke, dass in dieser Hinsicht auch das EF gehen müsste. Mal sehen vielleicht komme ich ja in den nächsten Tagen mal dazu in dieser Richtung mal zu testen.
Grüße
Thomas