Hallo Florian

Du nimmst dir einiges vor, aber es ist nicht so schlimm wenn man es mal versteht. Da EntityFramework im Grunde erstmal nichts mit der WPF zu tun hat werde ich den Beitrag verschieben. Du hast schon recht das viele vom EntityFramework sprechen wenn sie eine WPF Anwendung bauen. Hat aber nichts damit zu tun das es WPF ist sondern im Grunde einfach nur damit das EntityFramework im UnitOfWork Pattern gebaut wurde und somit wunderbar zum MVVM Pattern passt. Damit meine ich nicht das UOW wie MVVM ist aber es kann durch das Pattern sehr gut in eine Mehrschichtanwendung integriert werden und da es noch UnitTests unterstützt da EF Core auch einen InMemory-Provider mitbringt rundet da die Sache nochmals ab.

Ich gehe erstmal auf deine Punkte ein so gut ich kann.

1.) Ja, würde ich schon sagen, es muss allerdings ein wenig was gelernt werden.
2.) Im Grunde JEDE. Seit neuestem sogar NoSQL Datenbanken wie CosmosDB. Und zur not könnte man eigene Provider schreiben.
3.) Klar doch. Ich habe mehrere Bücher von Holger Schwichtenberg zum Thema EF Core. (Amazon)
Sind sehr gut geschrieben und er weis von was er redet. Ich durfte mich schon mit Ihm über EF Core und einiges unter der Haube unterhalten und muss sagen, der kennt sogar den Code bestens (ist ja OpenSource) und weis auch immer was Sache ist.

Die erste Anlaufstelle sollte folgende Seite sein: docs.microsoft.com/en-us/ef/core/
hier die verfügbaren Provider: docs.microsoft.com/en-us/ef/co…ers/?tabs=dotnet-core-cli

Erstmal was EF überhaupt ist. Genau, ein O/R Mapper.
Das bedeutet das EF ein Klassenmodell als Datenbank Mappt bzw. umgekehrt. EF kann voll konfiguriert werden und muss es des öfteren auch. Dennoch gilt bei EF Core "Configuration over Convention".
Für "normale" Modelle muss man im Grunde nichts extra über die sogenannte FluentAPI konfigurieren. EF Core mach einiges automatisch z.b. alleine Anhand des Benennung. Benennt man ein Property z.b. UserId geht EF Core davon aus das es ein Primärschlüssel werden soll da der Name des Properties mit ID endet. Auch Tabellenverknüpfungen untereinander können so hergestellt werden. So musst du in der Tabelle User nur ein Property "SettingId" einfügen und EF Core stellt die Verknüpfung zur Settingstabelle her. Will man das nicht müsste man es in der Konfiguration angeben. Deshablb "Configuration over Convention". Die Konfiguration wiegt also mehr.

Gut. Man bildet also seine Datenbank ab - mit dem Model. Super. Sind wir ja von MVVM also gewohnt. Macht also sinn.
Das gibt es die Context-Klasse. Die musst DU anlegen. Diese muss aber von DBContext im Namensraum EntityFramework (muss nicht genau der sein) erben.
In dieser Klasse erstellst du für jede "Tabelle" die es im Endeffekt geben soll ein PRoperty vom Typ "DBSet". Ein Typ des EntityFRameworks.

Und schon kannst du EF verwenden.

Einen wichtigen Punkt gibt es noch. Da EF Core die sogenannte "Migration" unterstützt sollte etwas wichtiges beachtet werden.
Aber zuerst. Migration? What? Ja. Stell dir vor du erstellt dein Modell. Du schreibst Daten und schreibst dein Programm. Es ist beim Kunden und der schreibt Daten.
Jetzt bekommt dein Programm ein neues Feature. Für das brauchst du eine neue Tabelle. In einer vorhandenen Tabelle änderst du eine Spalte (also ein Property in deinem Modell) und vieleicht erstellst du weitere Spalten (also PRoperties). Du startest deine Anwendung und es knallt. Tja, EF Core legt die Datenbank an wenn du es sagst. Normalerweise beim ersten Start. Aber es gleicht nicht ab ob später irgendwann die Struktur der Datenbank noch dieselbe ist wie dein Model. (EF 6 macht das bei jedem Start, EF Core nicht, was ich und viele andere besser finden, aber das ist ein anderes Thema)
Dafür gibt es die Migration. Du musst also eine Migration anstoßen. Migrations können über die Console in VS erzeugt werden. Diese erzeugen Migrationsklassen. In diesem Klassen ist er Code generiert welcher die Migration vornimmt. Das Tool unterstützt aber leider (wie immer) nur C# und kein VB.Net. Erstellst du also ein VB.Net PRojekt würden die Migrationsklassen dennoch in C# generiert. Klappt nicht - logisch.

Aber..... keine Bange. Da wir sowieso in der Welt der WPF ein eigenes Projekt mit dem Model haben (das ist die PRojekttrennung von der ich immer reden - tja - nicht umsonst) haben wir das Model in einem VB.Net Projekt.
Dann legen wir ein C# Projekt an. Nennen wir es "MeinTestContext" und dieses Projekt bekommt nur eine einzige Klasse. Deinen Context der von der von DBContext erbt.
Da die Migrationsfiles immer in dem Projekt abgelegt werden in welchem sich der Context befindet klappt nun auch alles. Und dieses Projekt hat einfach einen Verweis auf das Model-Projekt und gut ists.

Es gibt noch eine Menge Tipps und Tricks und es gibt viel zu beachten (z.b. bitte nie LazyLoading verwenden, auch wenn es verelockend klingt) aber dazu kommst du sicher noch.

Achja, die für dich wohl einfachste Möglichkeit an weiterführende Infos und Lernmaterial zu kommen ist wohl das Forum. Ich verwende EF seit mehreren Jahren und auch in Produktivumgebungen sowie Mehrmandantenprojekten über WAN und weis leider auch das man sich leicht "verzetteln" kann und schnell mal enorme Performanceschwierigkeiten bekommen kann, die liegen dann aber nicht an EF sondern so gut wie immer an der falschen verwendung oder das ignorieren von gewissen Einstellungen wie z.b. Tracking vs NoTracking, aber das steht ah alles in der Doku.

Schöne Grüße
Sascha

1.) WPF und EF sind nicht gekoppelt. Ich mach gerade auch meine ersten EF-Gehversuche - in WinForms.
2.) Such's Dir aus. Ne SQL-Datenbank. Anbieter für EF sind im MSDN aufgelistet. Ich selber nutze erstmal MariaDB (MySQL, Freeware)
3.) Natürlich angefangen beim MSDN. Ich hab mir noch auf Forenempfehlung mal das erste devcouch-Video angesehen. Ist zwar EF6, obwohl ich mit EF Core experimentiere, aber vom Prinzip her passt das schon.

Aber da kommen bestimmt noch die Pros und wissen und erzählen mehr und detaillierter.
Ah, da war ja @Nofear23m ein paar Sekunden schneller

Habe ich schon vor aber das dauert noch laaaange.

Grüße
Sascha

Die Sache ist die das es so wenig sinn macht. Ich habe ja auch das WPF notes Beispielprojekt mit EF Core und MVVM. Aber auch hier wirkt EF dann komplex weil es gleich mal über 3 Layer gereicht wird.

Am besten Lernst du EF Core und die Funktionsweise mit einer Konsolenapplikation. Klingt jetzt doof aber genau so würde ich es machen.
Und wenn man die Konsole doof findet dann von mir auch ne WPF Anwendung ohne MVVM oder Ähnlichem. einfach ein paar Buttons die dann etwas speichern oder Abrufen und in einem Textfeld oder ner Messagebox anzeigen.
Evtl. in der Messagebox auch noch die verbrauchte Zeit in Millisekunden ausgeben, denn gerade bei EF kann hier SEHR viel optimiert werden. Auch immer mit VIELEN Datensätzen probieren. Es gibt auch Seiten die bieten Beispieldatensätze zum herunterladen an. so kannst du gleich mit 200.000 Datensätzen die Performance austesten und wir sehen uns das hier dann mal gemeinsam an.

Grüße
Sascha

Meinst du nun beim start eine Konsolenanwendung oder beim start von EF?

Hallo

Wie schon oben Beschrieben solltest du mal schaun welchen Provider du nehmen willst. Ich nehme mal start an MS SQL oder MySQL.
Dann mal welche Version von EF Core. Bis Version (ich glaube) 2.2 wird das Full .Net Framework untestützt. Die 3.0 nur noch unter .Net Standard/.Net Core.

Dann mal ob du die Layer Model/Context trennen willst. Unter VB.Net im Grunde Pflicht, unter C# nicht.
Dann mal ein Testmodel machen. Vieleicht 2-3 Beziehungen und die ein oder andere Vererbung zum probieren rein.

Wenn das Model steht reden wir weiter.

Grüße
Sascha

Ich denke du kannst das hier gerne Anhängen. Außer natürlich es geht um was spezielles.

Also z.b. wenn du konkret jetzt keine Ahnung hast wie eine N:M Beziehung unter EF geht dann ist ein eigener Thread nützlich weil genau diese Stichwörter ja jemand in der Suche eingeben könnte.

Grüße
Sascha

Hallo Flori

Erstmal gehe ich auf deine WARUM Kommentare bei den Beziehungs-Properties ein.

Du hast recht, es ist über die ID mit dem anderen Objekt "verbunden" bzw. kann und wird von EF auch über diese die Verbindung zwischen den beiden Entitäten hergestellt. Aber. EFmacht dir hier das Leben leichter indem es (vorausgesetzt mal will das und gibt es auch in der Abfrage an) dir das Property befüllt.

Nehmen wir als Beispiel mal Song und Genre. Hier hast du in der Song Entität die GenreID und aber auch Genre vom Typ Genre. EF schreibt dir in GenreID die ID des verknüpften Genres rein und im Property Genre das Genre selbst. So musst du nun nicht umständlich über die ID nun die Daten Abrufen (was einen erneuten Roundtrip zur DB zur Folge hätte) sondern hast die Daten nun Bereits direkt enthalten.

Was mich an dem Model gerade irritiert ist die Entität SongInterpret. Die benötigt es nicht. Ein Song hat nur einen Interpret. Ein Interpret kann X Songs haben. Somit muss es im Song eine InterpretID und ein Property Interpret vom Typ Interpret geben. Und in Interpret ein Property Songs vom Typ List Of Song geben.

Ich hoffe das Hilft dir schonmal.

PS: Ich habe den Anhang deines letzten Posts entfernt, des ist im Forum nicht erlaubt eine exe zu haben. Bitte vor einem Upload immer den BIN Ordner entfernen.

Grüße
Sascha

Nofear23m schrieb:

Ein Song hat nur einen Interpret

Im allgemeinen, ja.

Es gibt auch Duos mit zwei Interpreten, die aber auch einzeln auftreten (z.B. Simon & Garfunkel).
Das Duo könnte man notfalls als eigenständigen Interpreten führen.

Was machen wir mit Duetten?
So was wie "Robbie Williams & Kylie Minogue - Kids"
Zwei an sich eigenständige Interpreten, die selten zusammen auftreten.

Oder ganz extrem:
"We Are The World" als Projekt mit sehr vielen bekannten Interpreten.
Gut, da könnte man "USA For Africa" als Interpreten verwenden.

Aber wie wir sehen, brauchen wir mit deiner Aussage immer in solchen Fällen eine Ausnahmeregelung, wenn keine echte 1:n-Beziehung nicht vorliegt.

Da hast du Recht @petaod.

Je nachdem wie Flori das möchte. In dem Fall benötigt er dann eine n:m Beziehung. Dann die zwischenentität auch korrekt nur muss diese dann aber auch verwendet werden. Wird sie aber nicht denn in Song ist die Eigenschaft nicht enthalten.

Hier man ein Link bez. n:m in EF Core:
docs.microsoft.com/en-us/ef/co…elationships#many-to-many

Grüße
Sascha

Hallo

Ok, bei einer M:N Beziehung passt das dann so mit der Zwischentabelle.

Contextklasse gibt es nur eine. Diese erbst von DBContext aus den EntityFramework Namensraum wue in den MS Docs angegeben. Schau dir in den MS Docs mal das Konsolenbeispiel an. In dieser Klasse gibt es dann für jede Entität ein Property vom Typ DBSet. Weiters muss dann über die Fluent API nich die Verknüpfung für die M:N Beziehung angegeben werden. Das kann EF nicht selbst und geht auch nicht über Annotation.

Dann vieleicht noch über die Fluent API die Indices setzen und fertig.

Sag bescheid wenn du wo probleme hast.

Grüße
Sascha