Entityframework und Prism

[Lemmy]

Hallo,

ich versuche mich gerade mit Prism und wollte mir da das Entityframework anschauen, allerdings kann ich das in Prism nicht finden. In Visual C# Express ist das aber auch dabei - wie bekomme ich das in Prism rein?

Grüße

[Furtbichler]

EF erzeugt C#-Code und da geht das mit Prism eben nicht. Wieso nicht mit C#?

[Phoenix]

Wenn Du EF Code First verwendest, dann brauchst Du keine Code-Generierung.

Diese Beispiele hier funktionieren genausogut mit Oxygene wie mit C#: http://www.codeproject.com/Articles/...t-Let-s-Try-It
Und du kannst den C#-Code auch gleich in Oxygene pasten.

[Furtbichler]

Und wenn nicht, hat er nur den halben Apfel.

[Lemmy]

@Phoenix: Danke für den Link

[Elvis]

Also wenn Lemmy wirklich ein EDMX anstatt Code-First nehmen will[1], kann er doch per T4 praktisch genauso den Code erzeugen, wie es auch für C# geht.

Ich habe kein Oxygene mehr, ansonsten hätte ich wohl in ein paar Minuten das bestehende C# .tt für einen Output in Oxygene umgemünzt.
Man braucht ja nur die Output language zu Oxygene ändern. Das ganze Inline C# kann ja C# bleiben.

[1]ist eine feine Sache, wenn der Designer anfängt zu spinnen und man dann mit dem Klotz am Bein da steht und eigentlich arbeiten wollte...

[Furtbichler]

Erinnert mich ein alten Freund, der Mini-Fan war (also die echten, alten). Der war dann so fixiert, das man eigentlich alles mit nem Mini anstellen kann, das er ganz stolz war, mit seinem Mini bis nach Italien gefahren zu sein, um einen Original-Motor abzuholen.

Ich fragte ihn, wieso er sich das Teil nicht hat schicken lassen, weil das a) genauso teuer und b) irgendwie bequemer ist. Gut: c) nicht so lustig, dafür d) ohne Bandscheibenvorfall.

Das ist so wie Prism und Visual Studio. Geht natürlich, hat seinen Charme, aber irgendwie gehts einfacher. Aber ich wiederhole mich und will nicht nochmal jemandem den Spaß verderben.

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

Zitat von Furtbichler (Beitrag 1195529)

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:

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: