Laden...

EntityFramework: Umstieg von ObjectContext zu DbContext

Erstellt von Diräkt vor 11 Jahren Letzter Beitrag vor 11 Jahren 3.464 Views
Hinweis von gfoidl vor 11 Jahren

Abgeteilt von [erledigt] EF Update / Delete ohne RoundTrip zur Datenbank

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 11 Jahren

Hallo Abt

Danke für die Erklärung !

Hallo gfoidl

Das geht aber nur wenn man nicht von ObjectContext abgeleitet hat sondern von DbContext.
(DbContext isteine Art Wrapper für den ObjectContext)

Beste Grüsse

Diräkt

16.834 Beiträge seit 2008
vor 11 Jahren

Naja als Wrapper zu bezeichnen ist vielleicht die richtige Richtung, aber 100%tig auch nicht.
Ab EF 4.1 Code First arbeitet man ausschließlich mit DbContext; ObjectContext alles davor.

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 11 Jahren

Hallo Abt

Da ich DB First arbeite, stellt sich nun natürlich die Frage, ob sich der Wechsel lohnt?!
(Bei DB First ist ObjectContext ja Standard (oder war zumindest immer so))

Ab EF 4.1 Code First arbeitet man ausschließlich mit DbContext

Das klingt als gäbe es dann "kein" Unterschied zwischen 4.0 und 5.0 wenn ich den ObjectContext weiterhin verwende ? (Was ist mit z.B Auto compiled Querys ?)

(ich weiss du hast es auf CodeFirst bezogen), aber hast du ggf. eine Antwort für mich bereit ? 😉

Beste Grüsse

Diräkt

16.834 Beiträge seit 2008
vor 11 Jahren

Auto Compiled Queries kann das EF erst vollständig ab 5.0 - außer Du benutzt den abgetöteten "Branch" June 2011 CTP, der allerdings keine ENums kann (und auch nicht weiter entwickelt wurde).

Ich war kein Freund von Code First, nutzte Model First über den Designer, weil das am Anfang alles sehr hakelig war. Code First hat enorm aufgeholt und alle anderen Ansätze in Features und Umsetzung weit hinter sich gelassen.
Seit 4 Monaten habe ich alle Projekte problemlos binnen kürzester Zeit migrigiert und verwende nur noch dieses.
Vor allem Code First Migrations sind was sehr sehr feines.

Was das ADO.NET Team da mit ihren Zwitter-Versuchen mit EF4.2/CTP June/EF 4.3 gemacht hat verstehe ich sowieso bis heute nicht.

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 11 Jahren

Hallo Abt

Ein Umstieg vom ObjectContext zum DbContext ist also relativ einfach, wie ich deinem Post entnehme sowie ein paar Ergebnissen von Google 😉

Ich war kein Freund von Code First...

Mir gings genau so, desshalb gehe ich bis heute den DB First weg. (Hab wohl was verschlafen 😉)

Gerne würde ich noch Deine persönliche Meinung hören bezüglich Umstieg (ObjectContext und DbContext) :

Muss ich mit stunden-langem Anpassen meiner BL Schicht rechnen ?

Wenn ich es richtig verstehe, bietet mir der DB Context unter anderem folgende Möglichkeiten:
=> Abrufen (Select) von einzelnen Spalten einer Tabelle (ohne die ganze Entity zu laden)
=> Updaten von einzelnen Spalten
=> ...

Beste Grüsse und Dank für Deine Zeit

Diräkt

Edit : Typo

6.911 Beiträge seit 2009
vor 11 Jahren

Hallo Diräkt,

der Umstieg ist relativ einfach, da die Methoden von der Semantik her ziemlich gleich sind. Ein paar Unterschiede gibts in der Bezeichnung, die mit DbContext näher am O von O/R sind. Z.B. heißt es Add statt AddObject und das passt ja besser zu ICollection<T>.
Insgesamt sollte die Portierung mit ein paar Compilerläufen (Fehler - beheben - kompilieren) schnell erledigt sein.

Mir ist DbContext viel lieber als ObjectContext, einfach das es für mich logischer aufgebaut scheint.

Bei neuen Projekten verwende ich nur Code-First, bei bestehender DB jedoch DB-First und dann einfach das "Code Generation Item" tauschen und fertig.

Zu deinen Fragen kann ich dir Using DbContext in EF 4.1 Part 1: Introduction and Model empfehlen, der Inhalt ist immer noch aktuell - so wie ich es sehe und verwende.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.834 Beiträge seit 2008
vor 11 Jahren

Naja mehr oder minder sind das einzelne Features. Für mich wars eben Enums und Code First Migrations..
Es war auch schon immer möglich nur einzelne Spalten zu laden....

Der größte Part beim Aufwand wird halt das Mapping, sofern Du das per Hand machen willst (was ich tu).

Wenn Du alles sauber gemacht und durchdacht hast musst Du nur innerhalb der DB Schnittstelle die Änderung vornehmen. Außen bleibt alles unberührt.
Paar Methoden heißen anders und im Repository musst eben auf DbSet / ICollection umsatteln.

Edit: den Rest hat gfoidl ja schon gesagt.

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 11 Jahren

Hallo Abt
Hallo gfoidl

Danke für Eure Antworten.

@gfoidl
=> Die Umstellung hat Problemlos geklappt, genau wie von Dir beschrieben.

@Abt

Es war auch schon immer möglich nur einzelne Spalten zu laden....

okay, und wie genau soll das gehen ?

context.Table.First().Name;

Wird eine Nullreference Exception auslösen, wenn kein Eintrag vorhanden ist.
Daher musst du ja erst die "row" selecten ?!
Auch die DbContext Mehtode

Find(pk)

macht nichts anderes ?!

Beste Grüsse

Diräkt

S
417 Beiträge seit 2008
vor 11 Jahren

okay, und wie genau soll das gehen ?

Z.b. so:

context.Table.Select(f => f.Name)