Entityframework und Prism

[Lemmy]

hi,

um mich hier nochmal einzuschalten: Es ist mir völlig wurscht wie die Technologie heißt (wenn ihr jetzt nicht gerade mit NHibernate kommt). Was ich will ist Erfahrung in Prism zu sammeln, und das mach ich mit einem kleinen Verwaltungstool, das ich für meinen Schwager schon mit Delphi gemacht habe.

Da reines ADO.NET anscheinend keiner mehr nimmt, kam eben das EntityFramework zur Sprache. Es sind zwar keine zwei Fragen in einem Thread erlaubt - aber eigentlich ist das ja auch keine Frage *fg*

gesucht ist eine Technologie für .NET um kleine Client/Server bzw. Desktop-DB Anwendungen zu schreiben. Wer hat hier Vorschläge bzw. bessere Alternativen für .NET / Prism. EF habe ich schon installiert und ersten COde geschrieben, geht zwar noch nicht, sollte aber nur an Kleinigkeiten fehlen.

@Furtbichler: KLar - einen großen Vorteil hat C# gegenüber Prism: Alles was man an Erklärungen im Netz findet bezieht sich auf C#.... Aber warum nicht auch über den Tellerrand schauen? Und wenn Du was hast, das nur mit c# funktioniert - warum nicht. Habe auch kein Problem mich damit noch auseinander zu setzen.

Grüße

[Furtbichler]

Es ist natürlich vollkommen legitim, wenn Du Prism benutzt, um Erfahrungen zu sammeln oder einen eigentlich funktionierenden Code an .net anzupassen.

Ado.net geht natürlich, wieso sollte das nicht gehen? Ich verwende das auch.

Du nimmst eine SqlConnection, SqlAdapter und DataTable oder einen SqlDataReader. Google doch mal nach "Ado.net read data". Und schreiben geht natürlich auch.

[Lemmy]

Zitat von Furtbichler:

Du nimmst eine SqlConnection, SqlAdapter und DataTable oder einen SqlDataReader. Google doch mal nach "Ado.net read data". Und schreiben geht natürlich auch.

keine Frage - nur war mir als ob das nicht mehr "hip" ist: Sorry finde auf die Schnelle den Thread nicht mehr. War vor kurzem hier im Forum ein paar Postings...

Grüße

[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 von Furtbichler:

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