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