Suchergebnisse

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…

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 i…

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…

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 a…

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 viele…

Hallo Als kleinen Tipp kann ich dir mitgeben während der Entwicklung ohne Migrations zu arbeiten. Da wirst du nicht fertig mit dem generieren der Migrationscripts. Ich mache das immer so das ich während der Entwicklung immer wenn ich etwas am Model ändere die DB lösche und mit dbContext.Database.EnsureCreated() gehe ich dann sicher das die DB beim Programmstart erstellt wird sollte diese nicht bereits existieren. Grüße Sascha

Hallo Soweis ich weis musst du nicht, es empfiehlt sich aber. Alleine aus Performancegründen. Soweit ich weis würde EF die Fremdschlüsselspalte in der DB auf jeden Fall anlegen. Klar, braucht es ja auch. Aber wenn du das Property in der Klasse nicht hast, hast du Nachteile. Wenn du einen Song abrufst von dem du im Moment noch nicht die Gerneinfos benötigst hast du (wenn du willst) dennoch die GenreID ohne dem Overhead eines Joins über die Genre-Tabelle. Willst du dann später (weil der User viele…