Hi,
Robert_G hat folgendes geschrieben: |
Geht sogar viiiiel besser als mit den komischen DataModules in Delphi. |
das freut mich zu hören.
Robert_G hat folgendes geschrieben: |
DataModules zwingen dich dazu globale Variable zu nutzen, wenn du ihren Inhalt im Designer sehen wilst.
Deshalb taugen die Viecher IMHOnicht viel mehr als irgendeine andere TComponent-Ableitung für sowas. |
Naja, man ist zwar gezwungen die Globale Variable im Quelltext stehen zu haben, aber wenn sie schlichtweg nicht genutzt wird (kein Autocreate für das DM) dürfte sie vom Linker wieder rausgeschmissen werden. Das ist nicht wirklich elegant, hat aber für die Praxis kaum Auswirkungen.
Robert_G hat folgendes geschrieben: |
In .Net kannst du einfach eine eigene Komponente anlegen, die dann auch eine Design-surface für non-visuelle Komponenten mitbringt.
Wenn du in dieser Komponente dann IListSource implemtierst, dann kannst du mehrere Datenquelle dem Designer zur Verfügung stellen. |
Cool, dann werde ich heute Abend mal versuchen das um zu setzen. Es hört sich auf jeden Fall vielversprechend an.
Robert_G hat folgendes geschrieben: |
IOW: Du kannst dann deine Komponente irgendwo drauf werfen und die Daten, die sie veröffentlicht an Controls binden, als wäre die Komponente ein DataSet. |
Hmm, das muss ich wahrscheinlich sehen um es richtig nachvollziehen zu können. Ich nehme an, du sprichst von der abstrakten Schnittstellenkomponente, da müsste ich aber noch im Quelltext festlegen welches Kindobjekt wirklich erzeugt wird oder übersehe ich wieder etwas (was gut möglich ist, da ich noch sehr in Delphi-Denke stecke)?
boombuler hat folgendes geschrieben: |
noch ein kleiner Tipp am Rande: Wenn du im Code nur die Abstrakten Klassen wie System.Data.Common.DbConnection usw. verwendest und dich da wo es möglich ist nur ANSI SQL verwendest hast du so gut wie keinen Portierungsaufwand für verschiedene Systeme. |
Ja, so ist das geplant. Zu 98% werden die einzelnen Schnittstellenimplementierungen einander gleichen. Die größten Unterschiede werden in die Kathegorie Tuning fallen, es gibt Operationen die bei DBMS A performant sind während sie DBMS B ausbremsen. Gelegentlich lohnt es sich auch die Reihenfolge der Bedingungen auf des DBMS anzupassen. Bei Komlexen oder sich häufig wiederholenden Operationen kann sich der Aufwand lohnen. Aber das hat
Robert_G ja auch gut erklärt.
// Edit: Dieses Post hatte ich ja ganz übersehen:
JüTho hat folgendes geschrieben: |
"Flexible" DB-Zugriffe wurden schon mehrfach entwickelt. Stichwort: O/R-Mapper. Sehr bekannt ist NHibernate. (Ich habe allerdings einen Bogen darum gemacht, weil das noch ein weiteres großes Thema für mich wäre.) |
Ich habe nicht vor da etwas von Drittanbietern zu benutzten. Denn zu viel Flexibilität verlangt meist zu viele Kompromisse. Die Schnittstelle wird sehr "speziell" auf meine Bedürfnisse zugeschnitten sein, also alles andere als Flexibel, lediglich die dahinterliegende Implementierung wird an das DBMS angepasst sein - sofern nötig (die meisten Zugriffe werden in der Art
SELECT A, B, C FROM MyTabelle WHERE (ID=XXXX) sein und hier gibt es nicht wirklich viel an das DBMS an zu passen).
Wie also z.B. was an welche DB zu übergeben ist kann ich sehr speziell implementieren wenn ich es für nötig erachte.
Gruß
Klabautermann