Da gibt es dann einen "dirty"-Trick... Man muss in der Spaltendefinition in Firebird den Kommentar der Spalte mit den Text "#PK_GEN#" belegen, also quasi
Code:
COMMENT ON COLUMN ANSCHRIFTEN.ID
IS '#PK_GEN#';
Das halte ich für eine unsaubere Umsetzung...
Naja, wenn du den Comment nicht nutzt, dann ist das einfach ein nachgeholtes Stück "Metadaten". Denn Firebird hat ja leider keine abfragbare Info darüber, dass ein Feld AutoInc'd wird.
Wenn der EF Provider sonst das tut was er soll, dann würde ich dir (gerade wenn ORMs-Neuland für dich sind) EF empfehlen.
NHibernate ist ungleich mächtiger, und man kann sich an praktisch allen Stellen selbst reinklinken und die Rädchen so einstellen, wie man es für sein Projekt haben will.
Allerdings muss man bei nHibernate wissen, wie man LINQ Queries schreiben muss, damit sie nicht zicken. (LINQ ist noch das große Manko von NHibernate)
Aber das ist alles für einen ORM-Einsteiger wohl etwas Overkill.
Fang also einfach mit EF an. Und wenn du den Comment brauchst, dann setz' ihn halt.
Stumpfsinniges Dogma kannst du dem Papst überlassen, das hat beim Programmieren nix zu suchen.
Kann denn Firebird mittlerweile vernünftig mit GUIDs umgehen? Wenn ja, dann gar nicht lange murksen und GUIDs anstatt Trigger und AutoInc nehmen.
btw: Kann der EF-Provider nicht die
DB passend für deine Klassen erzeugen? Mich würde ein Comment in der
DB nicht stören.
Die
DB ist ja nur das Teil, was die Daten speichert. Genau dafür hast du ja den ORM. Wie das da aussieht ist fast egal. (Darf nur nicht uneffizient sein)
Denn wenn du nicht gegen eine exakte
DB programmierst, sondern es dem ORM überlässt deine Klassen abzubilden, kannst du einfach auch mal postgres ausprobieren.
