ORM Framework empfehlung
verwendetes Datenbanksystem: SQL Server
Hallo allerseits
Da in nicht allzu ferner Zukunft einige entwicklungen in .net anstehen, möchte ich gerne wissen ob es für unsere Bedürfnisse ein gutes ORM-Framework gibt.
Eine der Schwierigkeiten ist, dass es mit dem bestehenden Datenmodell kompatibel sein müsste, und dieses ist aus meiner Sicht nicht gerade optimal:
Es wurde nach keiner Konvention erstellt (--> verschiedenartige Benennung der Tabellen, Schlüssel usw), Primärschlüssels sind z.T. mehrteilig und nicht automatisch mit "identity" generiert.
zudem müsste das Framework recht flexibel sein, denn bei der Entwicklung ist nicht 100% klar wie die Datenbank aussieht. Für kundenspezifische Anforderungen bezüglich der Datenerfassung können Felder in der Datenbank erstellt werden und diese können mit dem FormDesigner auf die Eingabemaske gesetzt werden.
Optionale Felder sollten möglich sein (Abfrage ob Feld vorhanden, falls ja: hole wert des DB-Felds, ansonsten default wert)
Die bisherige Software ist in Delphi programmiert, nicht wirklich nach Objektorientierten Grundsätzen und der Datenzugriff erfolgt über Datasets. Aber wenn sich nun die Gelegenheit bietet etwas neu zu entwickeln, dann würde ich dies gerne "richtig" tun und gerne auch auf ein ORM setzen...
Hab in einem ähnlichen Szenario sehr gute Erfahrungen mit nHibernate gemacht.
"Eine wirklich gute Idee erkennt man daran,
dass ihre Verwirklichung von vorneherein ausgeschlossen erscheint."
(Albert Einstein)
Hallo ogelogel,
willkommen beim myCSharp.de
das non plus ultra ist wohl immer noch NHibernate.
Damit kann man fast alles machen aber es ist ein bisschen fummelig da es keinen wirklich brauchbaren Designer gibt. Deshalb muss man sich selbst die Mappingdatei (als XML oder im Code) erstellen und die Objekte selbst anlegen.
Dadurch hat man bei einer kleinen Änderungen immer viele Punkte wo man was ändern muss.
Mit .Net 4 kam auch das Entity Framework 4 mit was IMHO echt brauchbar ist.
Es bietet auch ziemlich viele Funktionen und einen Top Designer.
Momentan arbeite ich hauptsächlich mit dem EF
Gruss
Michael
Du stellst das Fehlen des Designers als Nachteil hin. Gerade da sehe ich einen Vorteil, es gibt viel zu viel Designer-Zeug und die daraus entstehende Software ist mangels des Wissens der Interna oft eher mangelhaft.
Die Möglichkeit per Mapping Files (oder per ClassMaps via FluentNHibernate) vieles zu erreichen, ist vor allem bei Legacy-Portierungen extremst hilfreich.
Also Finger weg von Dro...Designern! 😁
"Eine wirklich gute Idee erkennt man daran,
dass ihre Verwirklichung von vorneherein ausgeschlossen erscheint."
(Albert Einstein)
Das sind auch die beiden Frameworks die mir bis jetzt ins Auge gefallen sind.
Einen fehlenden Designer werte ich auch nicht als Nachteil, vielleicht erschwert es aber die Akzeptanz bei anderen Entwicklern.
Auf jeden Fall ist es nicht einfach sich für etwas zu entscheiden ^^
Hallo kelkes,
ich habe es nicht als Nachteil hingestellt sondern nur gesagt dass es fummelig ist die ganzen Dateien per Hand schreiben zu müssen.
Klar, bei EF kann jeder Depp ein Mapping generieren lassen auch ohne zu wissen was im Hintergrund abläuft.
Aber ein Designer ist IMHO praktisch, da man sich direkt das Model aus einer bestehenden Datenbank generieren lassen kann.
Es ist sicher sauberer wenn man da manuell alles macht da man die Dinge bis ins kleinste Detail beinflussen kann.
Aber der EF Designer ist halt einfach praktisch, wenn man nur mal schnell was ändern will.
Da hat aber jeder seine eigene Meinung, was ich auch gut finde 😃
Gruss
Michael