Erfahrungen Firbird und ECO II ?

[Christof]

Hallo,

ich hätte mal eine Frage, hat jemand schon mal ECO II mit der Firbird Datenbank benutzt ?
Funktioniert das überhaupt ?
Bietet ECO II Vorteile bzw Nachteile gegenüber anderen Techniken?

Gibt es Alternativen wenn es um objektorientierendes-mapping zu relationalen Datenbanken (insbesondere Firbird) geht ?

Fragen über Fragen!
Vielen Dank im Voraus.


Gruß
Christof

[Robert_G]

Zitat:

Zitat von Christof

Hallo,

ich hätte mal eine Frage, hat jemand schon mal ECO II mit der Firbird Datenbank benutzt ?
Funktioniert das überhaupt ?
Bietet ECO II Vorteile bzw Nachteile gegenüber anderen Techniken?

Vorteil: Man muss nicht viel darüber nachdenken, was man da macht.
Nachteil: Man muss nicht viel darüber nachdenken, was man da macht. :mrgreen:
RIESEN Nachteil: Einfach mal bei QualityCentral vorbeischauen. ECO II ist genauso unzuverlässig wie Teil 1.
Ich fand ECO 1 anfangs echt cool. Aber irgendwann sitzt du da und musst realisieren, dass er deine Struktur nicht mehr abbilden kann.
Es kommt nur noch Kauderwelsch statt kompilierbarer Code raus.
zweiter Nachteil:
Du bist auf die Komponenten von ECO angewiesen. Du kannst zum Beispiel nicht mehr einfach eine Collection deiner Klassen an ein Control binden (jedenfalls keine Collection, die du nach deinen Bedürfnissen geschrieben hast ;) ).
ECO 1 hat dir ein DataGrid total verfriemelt: Es wurde zum Beispiel nicht mehr gezeigt welches Feld selektiert ist. Ich bin mir ziemlich sicher, dass ich das auch in der Bug liste zu ECO 2 gesehen habe. :gruebel:

Zitat:

Zitat von Christof

Gibt es Alternativen wenn es um objektorientierendes-mapping zu relationalen Datenbanken (insbesondere Firbird) geht ?

Es gibt da zum Beispiel NDO und das sehr vielversprechende Open Access (zur Zeit ist die Beta leider nur in der Lage MS SQL Svr anzusprechen :( ). Beide arbeiten nach dem Enhancer-Verfahren. Dabei werden deine Klassenbibliotheken nach dem Kompilieren disassembliert, mit der nötigen Persistenzfunktionalität versehen und wieder kompiliert.
Außerdem kannst du auf die Art deine Anwendung programmieren und aus den Metadaten der Klassen die DB erstellen lassen (der Weg geht natürlich auch andersherum).
Vorteile dieser Lösung:

• Sackschnell (hollow object fetching und kein Reflection nötig)
• Konsistenz! (dirty state management, cascadierendes Löschen/Aktualisieren)
• komplette Transparenz (deine Anwendung hat keinerlei Ahnung von der DB -> komplett DB-unabhängig)

Eine Lösung ohne Enhancer wäre die reine Verwendung von Attributen und Reflection.
Spezielle Klassen könnten dann aus diesen Informationen zur Laufzeit SQL Statements bauen und deine Objekte erstellen. (An dem Weg bastel ich gerade in meiner "Freizeit" ;) )
Diese Lösung per Reflection hat aber den Nachteil, dass man viel mit dyn. Assemblies arbeiten muss um nicht in eine Performancefalle zu tappen. Außerdem sollte man sich gut mit Reflection auskennen. ;)

[Christof]

Vielen Dank für die ausführliche Antwort.

Also bleibt mir momentan nur die Daten per ADO aus der Datebank zu holen und manuell daraus Objekte zu konstruieren und diese in Collection zu verpacken (z.B. eine Datenmenge in einem DatenGrid anzeigen lassen), oder ?


Dann muss ich meine Klasse so bauen, dass alles z.B. bei einem Dispose auch in der Datenbank nachgezogen wird, oder?

Wenn ich aber denke ich lösche mit einem dispose so 50 Objekte, dann wird ja immer eine Datenbankanfrage für jedes einzele Objekt ausgeführt oder geht das besser ?


Gruß
Christof

[Robert_G]

Zitat:

Zitat von Christof

Vielen Dank für die ausführliche Antwort.

Also bleibt mir momentan nur die Daten per ADO aus der Datebank zu holen und manuell daraus Objekte zu konstruieren und diese in Collection zu verpacken (z.B. eine Datenmenge in einem DatenGrid anzeigen lassen), oder ?

Darauf läuft jede Lösung hinaus. ;)

Zitat:

Zitat von Christof

Dann muss ich meine Klasse so bauen, dass alles z.B. bei einem Dispose auch in der Datenbank nachgezogen wird, oder?

uff :shock:
Les' dir das nochmal genau durch...

Das hier würde ja dann ein Löschen des Datensatzes bewirken:

Code:

using(SomeDbClass otto = new SomeDbClass("Otto", "Meyer"))
{
  otto.SomeProperty = SomeValue;
}

Oder hab' ich das jetzt falsch verstanden? :gruebel:

Zitat:

Zitat von Christof

Wenn ich aber denke ich lösche mit einem dispose so 50 Objekte, dann wird ja immer eine Datenbankanfrage für jedes einzele Objekt ausgeführt oder geht das besser ?

Du könntest doch in deiner Liste alle "gelöschten" Instanzen mitführen, bei einem Update kannst du sie in einem Rutsch in der DB löschen, einfügen oder altualisieren.
Wobei du in FireBird sowieso immer einzelne Statements pro Objekt absetzen musst. FB kennt ja kein Bulk DML. ;)

btw: Du warst doch der Christof, dem ich ein Tutorial versprochen habe...
Ich sitze immer noch an dem Versuch Reflection vertändlich rüberbringen zu können... :gruebel:

[Christof]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Christof

Vielen Dank für die ausführliche Antwort.

Also bleibt mir momentan nur die Daten per ADO aus der Datebank zu holen und manuell daraus Objekte zu konstruieren und diese in Collection zu verpacken (z.B. eine Datenmenge in einem DatenGrid anzeigen lassen), oder ?

Darauf läuft jede Lösung hinaus. ;)

Zitat:

Zitat von Christof

Dann muss ich meine Klasse so bauen, dass alles z.B. bei einem Dispose auch in der Datenbank nachgezogen wird, oder?

uff :shock:
Les' dir das nochmal genau durch...

Das hier würde ja dann ein Löschen des Datensatzes bewirken:

Code:

using(SomeDbClass otto = new SomeDbClass("Otto", "Meyer"))
{
  otto.SomeProperty = SomeValue;
}

Ich meine wenn ich ein Objekt zerstöre dann muss ich es ja auch in der Datenbank löschen.
Bzw. ein Update hätte auch ein Update in der DB zur Folge, d.h. die Datenbank hat viel zu tun, wenn dies zeitnah passiert.

Zitat:

Zitat von Robert_G

Oder hab' ich das jetzt falsch verstanden? :gruebel:

Zitat:

Zitat von Christof

Wenn ich aber denke ich lösche mit einem dispose so 50 Objekte, dann wird ja immer eine Datenbankanfrage für jedes einzele Objekt ausgeführt oder geht das besser ?

Du könntest doch in deiner Liste alle "gelöschten" Instanzen mitführen, bei einem Update kannst du sie in einem Rutsch in der DB löschen, einfügen oder altualisieren.

Wenn dies in einer Multiuserumgebung stattfindet muss ich alles zeitnah aktualisieren sonst kann es zu Konfikten kommen, wenn die Datenmengen von der Datenbank neu angefordert werden muss.

Zitat:

Zitat von Robert_G

Wobei du in FireBird sowieso immer einzelne Statements pro Objekt absetzen musst. FB kennt ja kein Bulk DML. ;)

Dann hat die Datenbank viel zu tun.
Wenn ich eine große Multiuserumgebung habe führt das nicht zu Performaceproblemen?
Sind diese Performaceprobleme bei den fertigen Frameworks beseitigt oder noch schlimmer ?

Zitat:

Zitat von Robert_G

btw: Du warst doch der Christof, dem ich ein Tutorial versprochen habe...
Ich sitze immer noch an dem Versuch Reflection vertändlich rüberbringen zu können... :gruebel:

Genau der bin ich.
Danke nochmal. Fragen über Fragen!

Gruß
Christof

[Christof]

verdammt falscher button