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.
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.
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.