Erfahrungen ORM mit Firebird

[Lemmy]

Hi,

erzähl doch erst mal warum du ein ORM einsetzen willst. Da du auf Firebird abfährst vermute ich, dass das Thema unterschiedliche DBs schon mal außen vor ist. Dann kann es durchaus sinnvoll sein, sich mit dem Thema "eigenes ORM" zu beschäftigen.

Ich kenne mich jetzt mit C# nicht wirklich gut aus, bin aber der Meinung, dass das schon einige Dinge mitbringt um ein eigenes kleines ORM in einem vertretbaren Zeitrahmen umzusetzen (De-/Serialisierung, Objekte an Oberfläche hängen,....). Habe so was mal mit Delphi gemacht, und würde nach dem Test verschiedener ORM (InstantObjects, tiOPF, NHibernate,...) im nächsten Projekt wo so was Sinn macht vermutlich wieder so beginnen. Zum einen ist die Einarbeitung in ein ORM nicht zu verachten, zudem kann es auch sein, dass die Philosophie eines Frameworks einfach nicht zur Aufgabenstellung passt. Zudem hast Du bei einem leichtgewichtigen eigenen ORM immer noch die Möglichkeit über einen Direktzugriff auf die DB gewisse kritische Funktionen entsprechend schnell auf der DB auszuführen.

Grüße

[Morphie]

Zitat von Lemmy:

erzähl doch erst mal warum du ein ORM einsetzen willst. Da du auf Firebird abfährst vermute ich, dass das Thema unterschiedliche DBs schon mal außen vor ist. Dann kann es durchaus sinnvoll sein, sich mit dem Thema "eigenes ORM" zu beschäftigen.

ADO.NET in Verbindung mit WPF lädt ja quasi dazu ein, die Daten irgendwie zu mappen und anschließend als Objekte weiterzuverwenden / an die Oberfläche zu binden.
Das Abfragen der Daten über LINQ empfinde ich auch als sehr angenehm...

So ein ORM nimmt mir halt viel Arbeit ab.
Die generierten Klassen haben schon alle die gewünschten Interfaces implementiert und sind für mich leicht zu erweitern.

Vorher habe ich viel mit reinem SQL (Command + DataReader) materialisiert. Das ging zwar richtig schnell und ich konnte die ganzen Features von Firebird benutzen, doch es war sehr aufwändig.

Mit DataSets konnte ich mich nie wirklich anfreunden.
Jetzt hat man schon mal so eine stark objektorientierte Programmiersprache, dann will man auch mit echten BusinessObjekten arbeiten...

Zitat von Lemmy:

Zum einen ist die Einarbeitung in ein ORM nicht zu verachten, zudem kann es auch sein, dass die Philosophie eines Frameworks einfach nicht zur Aufgabenstellung passt. Zudem hast Du bei einem leichtgewichtigen eigenen ORM immer noch die Möglichkeit über einen Direktzugriff auf die DB gewisse kritische Funktionen entsprechend schnell auf der DB auszuführen.

So denke ich auch...