Laden...

EF 6 Fluent API bei DatabaseFirst

Erstellt von m.grauber vor 10 Jahren Letzter Beitrag vor 10 Jahren 3.915 Views
M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 10 Jahren
EF 6 Fluent API bei DatabaseFirst

verwendetes Datenbanksystem: <SQL-Server 2012>

Hallo!

Ich bin noch an der Umstellung von EF 5 + Object-Context + Database First nach EF 6 + DbContext + Database First.

Ich nutze den EDMX-Designer und "Entity Framework 6.0.2 Tools for Visual Studio 2012" sind installiert.

Inzwischen habe ich mich sehr in das EF 6 eingearbeitet, habe aber folgendes Problem, da meist nur EF6+CodeFirst beschrieben wird, ich aber vorerst bei DataBase First bleiben möchte.

Bei ObjectContext unter EF5 hat der EDMX-Designer immer alle Key-Annotations plus alle Beziehungen selbst erstellt. Das macht er jetzt nicht mehr, sondern legt nur noch die nakten Entity-Klassen an. Im EDMX-Designer zeigt er aber trotzdem bei den Schlüsselspalten ein Bild mit einem Key davor.

  1. Ist das ein Fehler im Designer oder muss ich nun diese Sachen selbst machen, obwohl ich DatabaseFirst nutzen möchte und alle Keys und Beziehungen in der Datenbank bereits vorhanden sind?

Falls ich sie selbst machen muss, habe ich mich für Fluent API (statt DataAnnotations) entschieden: Mit HasKey den Schlüssel für alle Entitäten festgelegt und mit HasRequired die Tabellenbeziehungen.

Leider kommt nun noch beim 1. Ausführen des 1. Linq-Befehls folgender Fehler:

Das Unterstützungsmodell des Kontexts 'MyEntities' wurde seit der Erstellung der Datenbank geändert. Sie können Code First-Migrationen verwenden, um die Datenbank zu aktualisieren (
>
).

So und jetzt bin ich wieder auf der Webseite vom Anfang. Er möchte unbedingt den Codefirst-Ansatz und sagt mir nicht, wo genau der Fehler liegt!

Brisant dabei: In der Linq-Abfrage wird eine Tabelle abgefragt, die nur einen Key, aber keine Beziehung hat und der Key wurde mit HasKey ordentlich definiert.

Ich habe im EDMX-Designer bereits eine Validierung und Aktualisierung durchgeführt, jedoch ohne diesen Fehler wegzubekommen.

  1. Es scheint irgend etwas in der Datenbank und im Model noch anders zu sein. Nur wie finde ich es heraus was genau das ist?

  2. Sollte ich vielleicht den EDMX-Designer zukünftig nicht mehr benutzen und komplett auf den CodeFirst-Ansatz umswitchen? Achtung: Die Tabellenerstellung und Updatefunktion habe ich derzeit in einem Updateprogramm durch SQL-Befehle geregelt. Das sollte, wenn möglich, auch zukünftig weiter genutzt werden - statt dem CodeFirst-Tabellen-Updateprozess (obwohl dieser relativ stimmig erscheint).

Vielen Dank für Eure Hilfe!

Warnung von Abt vor 10 Jahren

Bitte endlich das Fettschreiben von 50% des Beitrags unterlassen. Danke.

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

211 Beiträge seit 2008
vor 10 Jahren

Hi,

also wenn du Database First verwendest, empfehle ich dir einfach mal das Model von der Datenbank upzudaten und davor ev. das Model selbst zu leeren damit es Konsistent mit der Datenbank ist.

  1. Ich glaube nicht, dass es ein Fehler ist. "Convention over Configuration" bedeutet es werden gewisse Standardeinstellung vorgenommen. Zum Beispiel wenn ein Property ID heißt, wird das automatisch zu einem PK Attribut.

  2. Ich kann mir leider auch nicht vorstellen wo du die Attribute direkt hinschreibst? In den Output der TT - Files? Dann sind die Änderungen beim nächsten Speichern des Models wieder weg. Zusätzlich wäre das Attribut für ein Schlüsselattribut "Key" und nicht "HasKey".

  3. Wenns wirklich Database First ist - Model kicken, und von der Datenbank abholen erneut

  4. Kommt m.M.n auf die Richtung der Änderungen an. Hast du die Gewalt über das Design der Datenbank? Dann finde ich es einen sehr eleganten Weg alleine wegen den Migrations. Hast du diese nicht, kann ich davon nur abraten, da du dir damit mehr Probleme einfängst.

Kontakt & Blog: www.giesswein-apps.at

W
955 Beiträge seit 2010
vor 10 Jahren

Ist denn die MigrationHistory-Tabelle noch drin?

M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 10 Jahren

Hallo Witte!

Nein. Da ich vom ObjectContext komme, habe ich noch keine einzige Migration über Nuget gemacht und es gibt dafür auch keine CS-Files.

Es existiert nur die grafische EDMX-Datei, die die Entitätsklassen unter sich erstellt hat. Allerdings nur die einzelnen Felder ohne die Annotations. Das ist ja eigentlich auch der richtige Ansatz, da ich derzeit nicht CodeFirst nutze und auch nicht möchte.

Grüße

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

M
m.grauber Themenstarter:in
343 Beiträge seit 2010
vor 10 Jahren

Hallo LatinChriz!

Wieder einmal vielen Dank für die Hilfe! 👍

empfehle ich dir einfach mal das Model von der Datenbank upzudaten und davor ev. das Model selbst zu leeren damit es Konsistent mit der Datenbank ist

--> Ich habe schon alles versucht: über Kontextmenü "Aktualisieren", eine einzelne Tabelle zu entfernen und wieder einzufügen, Alle Tabellen aus dem grafischen Designer gelöscht, Programm bereinigt dann neu gestartet und alle Tabellen wieder hinzugefügt (und dabei die Anordnung aller Tabellen im Designer verloren) Alles ohne Erfolg. Gleiche Fehlermeldung.

1.) Auch sind die Annotations nicht drinnen, was aber verständlich ist, da die ältere Datenbank sich a) NICHT an die normierte Feldbeschreibung hält und b) die Keyspalten vom Typ GUID sind - was aber nach einigen Webseiten kein Problem bedeuten sollte. Jedoch werden im grafischen Designer die Schlüsselspalten mit einem Schlüsselsymbol korrekt markiert.

Daher habe ich die Zuweisungen per FluentAPI gemacht.

2.) Ja der EDMX-Designer würde alle Annotations nach einer Änderung entfernen. Daher nutze ich Fluent API und da die DbContext Klasse partial ist, mache ich das in meinen eigenen Dateien. Du schreibst "[Key]" statt Haskey. [Key] ist aber der andere Weg über Dataannotations.

3.) Siehe Zitat oben, alles schon versucht

4.) Da die Datenbank schon älter ist und "draußen" existiert und einige DBA's sehr eigen sind, würde ich schon gerne beim DatabaseFirst Ansatz bleiben.

Was ich halt nicht verstehe ist, dass es bei ObjectContext alles vom Designer automatisch gemacht wurde (Key und Beziehungen) und nun nach dem Update auf EF 6.1 nicht mehr.

Vielleicht noch irgendwelche Tipps?

P.S. Die Fettschreibung hatte ich zur besseren Übersicht gewählt, es sollte nicht als "schreien" aufgefasst werden.

Danke

Mfg
Michael

PS: Ich stelle nur Fragen, wenn ich in Büchern, im Web und in Foren nichts gefunden habe. Dumme Fragen bitte ich zu entschuldigen!

:] VISUAL STUDIO 2017 + .NET FRAMEWORK 4.5 + SQL-Server 2012 :]

16.842 Beiträge seit 2008
vor 10 Jahren

Vielleicht noch irgendwelche Tipps?

Zum 8764324 mal: auf den Designer verzichten, endlich EF verstehen lernen (wozu auch die FluentAPI gehört, und zum wiederholten male auch POCO) und mit Code First richtig anwenden.