Entityframework und Prism

[Furtbichler]

Na und? Wenn Du so ein lebendes und sich ständig weiterentwickelndes Ding wie EF umbiegst, damit es prototypisch wenigstens 1x für dein Prism passt, dann musst du dich dann damit abfinden, das Du bei der nächsten Änderung gleich wieder von vorne anfangen musst (außer, die .tt-Dateien ändern sich eh nicht).

Wenn Du den ORM experimentieren willst, dann würde ich wirklich Abschied von Prism nehmen. Heule mit den Wölfen, verwende 'den' Standard. Im Endeffekt hast Du imho mehr davon.

[Lemmy]

OK und welches (kleines) Framework würdest du dann bei C# einsetzen?

[Furtbichler]

Bei C# bin ich wirklich mit dem EF schnell zum (kleinen) Ziel gekommen. Eine DB mit ca. 20 Tabellen und einzelnen Objekten, also keine hochperformante Geschichte ohne Sonderfälle. Die Cracks hier würden Dir vermutlich zu NHibernate raten, das kenne ich nicht. Aber ich bin da kein Spezialist. EF ging einfach schnell in der Umsetzung.

Beruflich werden wir XPO von DevExpress einsetzen, das gibt es schon 8 Jahre (ca.) und sollte keine Kinderkrankheiten mehr haben.

[Lemmy]

nHibernate ist für mich nichts - ich halte nichts davon zentrale Inhalte meiner Applikation per XML-Definitionsdateien zu definieren, die erst zur Laufzeit ausgewertet werden und fehlerhaft sein können.

[Morphie]

Zitat:

Zitat von Furtbichler (Beitrag 1195544)

Beruflich werden wir XPO von DevExpress einsetzen, das gibt es schon 8 Jahre (ca.) und sollte keine Kinderkrankheiten mehr haben.

setzt ihr ein, oder wollt ihr einsetzen?
Als wir es bekommen haben, wollte ich mal ganz eifrig XPO mit Firebird benutzen... Musste aber feststellen, dass XPO irgendwie nicht mit Firebird 2.5 klar kommt.

Da ist das EntityFramework klar im Vorteil. Zugegeben, Firebird ist im .NET-Bereich ja doch schon eine Ausnahme...


edit: Ich habe auch noch gute Erfahrungen mit den Telerik OpenAccess ORM gemacht. Ist Freeware und leicht erweiterbar...

[Furtbichler]

[QUOTE=Morphie;1195546]

Zitat:

Zitat von Furtbichler (Beitrag 1195544)

Als wir es bekommen haben, wollte ich mal ganz eifrig XPO mit Firebird benutzen... Musste aber feststellen, dass XPO irgendwie nicht mit Firebird 2.5 klar kommt.

Komisch, wir haben drei RDBMS, eins davon ist FB und ich meine, die 2.5er. Ich habe als erstes eine ServerModeCollection über eine (allerdings dynamisch erstellte) XPO-Klasse auf FB losgelassen und hatte null Probleme. Der XPO ORM Wizzard ist erst seit letzter Woche für VS2012 enthalten, aber ich kann mich nächste Woche mal ransetzen.

Zitat:

edit: Ich habe auch noch gute Erfahrungen mit den Telerik OpenAccess ORM gemacht. Ist Freeware und leicht erweiterbar...

Da wir erst im Aufbau sind, haben wir noch ein paar Wochen Zeit. Ich schaue mir das mal an. Danke für den Tipp.

Und bei der Gelegenheit auch NHibernate.

[Elvis]

Zitat:

Zitat von Lemmy (Beitrag 1195545)

nHibernate ist für mich nichts - ich halte nichts davon zentrale Inhalte meiner Applikation per XML-Definitionsdateien zu definieren, die erst zur Laufzeit ausgewertet werden und fehlerhaft sein können.

Wenn du Mappings per XML machst (ich mache das, viele machen das lieber per Code), dann bekommst du dafür im VS code completion und Prüfungen. (nHibernate bringt ein XSD mit)

Für den Anfang ist da Fluent nHibernate IMO besser, denn für den Anfang ist es dir egal, ob die DBAs beim Kunden die Mappings auch auf eine andere DB anpassen können oder nicht.

Wenn du VS2010 oder VS2012 hast, besorge dir erstmal NuGet über den Extension Manager.
Dann kannst du einen Rechtsklick auf dein Projekt machen und auf Manage Nuget packages klicken.
Dort einfach nach FLuent nhibernate suchen und installieren. Nuget wird jetzt autom. alle Abhängkeiten laden und deinem Projekt als Referenz hinzufügen.

Alles weiterführende wird für "Entityframework und Prism" mehr als nur Offtopic.. ;-)
Es gibt aber sehr, sehr viele Quellen im Netz, dir dir Fluent nHibernate an einfachen Beispielen erklären.

Allerdings ist es für den Anfang auch absolut, problemlos möglich Code-First mit dem EF auszuprobieren.
Es gibt ebenfalls sehr, sehr viele Beispiele von Code-First mit dem EF.
Den EDMX Designer sollte man IMO komplett ignorieren.
Da hast du unglaublich viel in einem einzigen File drin. Wehe wenn der Designer spinnt (und das macht er), oder wenn du einen Branch mergen willst. Merging von EDMX-Dateien ist krank... :freak: