Abgeteilt von [erledigt] EF Update / Delete ohne RoundTrip zur Datenbank
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
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
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!"
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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
okay, und wie genau soll das gehen ?
Z.b. so:
context.Table.Select(f => f.Name)