EntityFramework: CodeFirst vs. ModelFirst

  • WPF

Es gibt 55 Antworten in diesem Thema. Der letzte Beitrag () ist von Mono.

    OK, also leider ist das Thema ja tot bevor es überhaupt begonnen hat.
    Bin ich schon ein wenig enttäuscht muss ich sagen, das hätte ein guter vergleich werden können.

    @MrTrebron vielen Dank für deine Mühe.
    An alle:
    Probiert EF aus. Es ist wirklich gut und gerade EF Core ist extrem performant.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich finde es auch schade, das dieses Thema nicht weiter behandelt wird. Habe gehofft, das ich noch was lernen kann. Ich habe mich viel mit EF beschäftigt. Da ich damit eigentlich zufrieden bin, kenne ich kein anderes Framework. Ich habe DB First, Model First und Code First probiert und bin beim Letzteren hängen geblieben. Es ist einfach zu einfach. Mit wenigen Zeilen Code kann man eine Datenbank erstellen. Hier mal ein Beispiel:

    Diese 3 Klassen sind mein Model.

    C#-Quellcode

    1. namespace ShopBlank
    2. {
    3. public class Artikel
    4. {
    5. public int Id { get; set; }
    6. public string Name { get; set; }
    7. public decimal Preis { get; set; }
    8. }
    9. }



    C#-Quellcode

    1. using System.Collections.Generic;
    2. namespace ShopBlank
    3. {
    4. public class Rechnung
    5. {
    6. public int Id { get; set; }
    7. public string Besteller { get; set; }
    8. public List<RechnungsPosition> Positionen { get; set; }
    9. }
    10. }



    C#-Quellcode

    1. namespace ShopBlank
    2. {
    3. public class RechnungsPosition
    4. {
    5. public int Id { get; set; }
    6. public int Menge { get; set; }
    7. public Artikel Artikel { get; set; }
    8. }
    9. }



    ​So um daraus eine Datenbank zu erstellen brauchen wir noch den DbContext.


    C#-Quellcode

    1. using System.Data.Entity;
    2. namespace ShopBlank
    3. {
    4. public class ShopDbContext : DbContext
    5. {
    6. public DbSet<Artikel> Artikels { get; set; }
    7. public DbSet<Rechnung> Rechnungen { get; set; }
    8. }
    9. }



    ​Upps nun haben wir lauter Fehler. Das liegt daran, das wir das Entity Framework noch nicht installiert haben.
    Das geht folgender maßen:
    ​Rechtsclick auf unser Projekt und NuGet-Pakete verwalten anclicken. Dann öffnet sich ein Fenster wo wir im Suchfeld Entity Framework eingeben. Dann einfach den Anweisungen folgen.

    Nun müssten die Fehler verschwunden sein.
    ​Viele arbeiten noch mit Model First, Weil sie gerne grafisch sehen wollen was man fabriziert. Das geht auch bei Code First. Dazu müssen wir uns aber erst eine Extension installieren. Das geht wie folgt:
    ​Installieren der Entity Framework 6 Power Tools Community Edition.


    ​Nun können wir uns unser Model grafisch darstellen lassen. Einfach mit der rechten Maustaste auf unsere DbContext Klasse clicken.


    Die Datenbank wird erst erzeugt, wenn wir auf diese zugreifen wollen. Also schreiben wir noch ein kleines Programm.

    C#-Quellcode

    1. using System.Collections.Generic;
    2. namespace ShopBlank
    3. {
    4. class Program
    5. {
    6. static void Main(string[] args)
    7. {
    8. using (var ctx = new ShopDbContext())
    9. {
    10. var holz = new Artikel { Name = "Holz", Preis = 5.99m };
    11. var blume = new Artikel { Name = "Blume", Preis = 0.99m };
    12. ctx.Artikels.Add(holz);
    13. ctx.Artikels.Add(blume);
    14. var rechnung = new Rechnung
    15. {
    16. Besteller = "Max Musterman",
    17. Positionen = new List<RechnungsPosition>
    18. {
    19. new RechnungsPosition {Artikel = holz, Menge = 2},
    20. new RechnungsPosition {Artikel = blume, Menge = 10}
    21. }
    22. };
    23. ctx.Rechnungen.Add(rechnung);
    24. ctx.SaveChanges();
    25. }
    26. }
    27. }
    28. }


    Wenn wir das Programm starten, dauert es ein wenig, weil die DB erst erstellt werden muss. Nach geglückten Programmdurchlauf (Es wird nichts im Programmfenster dargestellt) können wir im SQL Server-Objekt-Explorer folgende DB finden(evtl. vorher aktualisieren).

    Nun kann man sich auch die Daten anzeigen lassen.


    ​Wie man sieht geht es ganz einfach eine kleine DB zu erstellen. mit der man eigentlich schon ganz gut arbeiten kann.
    Bitte bedenkt, das es nur ein Bsp. ist.
    Bilder
    • NuGetEF.jpg

      429,72 kB, 1.117×646, 212 mal angesehen
    • Extension.jpg

      406,59 kB, 1.117×646, 170 mal angesehen
    • EF6PTCE.jpg

      373,04 kB, 941×653, 202 mal angesehen
    • EntityFrameworkPowerTools.jpg

      406,5 kB, 1.117×646, 319 mal angesehen
    • ShopDiagramm.jpg

      348,45 kB, 1.117×646, 320 mal angesehen
    • Datenbank.jpg

      304,43 kB, 1.117×646, 180 mal angesehen
    • Daten.jpg

      280,84 kB, 1.117×646, 165 mal angesehen
    Hallo @hlghyr

    Hast dir ja viel Arbeit gemacht. Das Thema ist vermutlich hier erledigt.
    Das bedeutet aber nicht das du nicht ein Thema aufmachen kannst wenn du irgendwo fragen hast.

    Mittlerweile bin ich sowieso der Meinung das man eher wenn überhaupt über EF Core reden sollte.
    EF 6 wird zwar noch weiter entwickelt aber nur solange bis EF Core fertig ist.
    Mit der nächsten Version im 2. Quartal wir schon so viel drinnen sein das man kein EF 6 mehr verwenden muss, selbst in Produktivsystemen nicht.

    In diesem Sinne.

    Schöne Ostern
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hi @Nofear23m!
    ​Das mit EF Core habe ich mitbekommen und das da zZ. sehr viel Ressourcen reingesteckt werden deutet auch darauf hin, das man es auf jeden Fall im Auge behalten sollte. Des weiteren, ist es für mich nur ein Versuch das Thema am laufen zu halten.

    ​Frohe Ostern Helge
    Verstehe ich. Toll das du dir die mühe machst, finde auch recht seltsam das gerade derjenige welcher den Thread aufmacht kein Interesse zeigt.
    Aber.... wir können gerne ein Thema aufmachen. "EF Core - Was ist anders, was kann es, was kann es nicht"

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hi @Nofear23m!
    ​So ein Thema würde ich sehr begrüßen. Doch wäre meine Hilfe gegen 0, da meine Kenntnisse was EF Core angeht minus1 sind. Jedoch kann ich mir gut vorstellen, das die Unterschiede nach außen nicht so doll sein können. im Innern soll es ja komplett neu sein.
    Hallo

    Das macht nichts, auch fragen sind eine Hilfe. Wenn jemand diese beantworten kann ist hier der ganzen Community geholfen.
    Vieles ist gleich, die "Anwendung" selbst ist sogar völlig gleich. Es gibt ein paar kleine Unterschiede und auch ein paar Fallstricke (wie auch bei EF6) die es zu beachten gibt.
    Ansonsten ist der größte Unterschied das es auch allen Plattformen laufen kann, viel performanter ist und die Migrationen anders laufen.

    Achja, und OutOfTheBox kein ModelFirst oder DBfirst, nur mit Addons von Drittanbietern.

    Mal sehen, vielleicht meldet sich noch jemand dann kann man ja einen Thread aufmachen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Kleiner Tip. Mach mal ein paar Tests.

    Ein bereits bestehendes umzustellen ist mitunter sehr viel Arbeit und birgt sehr viele Hindernisse.
    Sei vorsichtig.

    Mach lieber ein neues Testprojekt wo du ein wenig rumspielen kannst. Denn auch wenn die art und weise wie man Daten abruft oder speichert gleich blieb ist doch einiges anders wie z.b. das es noch(!!) kein korrektes LazyLoading gibt. Ich persönlich hatte LazyLoading eh noch nie gerne gesehen und würde mir wünschen sie hätten es von der Agenda genommen aber OK.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ja muss sowieso erst mal sehen wie das mit den n:m Beziehungen ist. Glaube da mal was gelesen zu haben, das das noch nicht funzt. aber das ist schon ewig her und könnte jetzt anders sein. Naja! Mein OrginalProjekt werde ich nicht nehmen. Höchstens eine Kopie.
    Hallo

    Der einzige Unterschied ist nur das man die Zwischentabelle "selbst" erstellen und angeben muss. Bin ich aber fast schon ein Freund davon. Ich entscheide gerne selbst was ich mache.
    Wenn ich eine DB erstelle und ich mache DB First dann erstelle ich ja auch die Zwischentabelle selbst. Also warum nicht bei CodeFirst auch.
    MS will das aber nachreichen.

    Derweil mache es einfach so: Diese hier in der Doku.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Man kann auch mit EF Core DB First umsetzen.
    Zumindest für den Anfang. Es gibt bei den Tools ein Scaffold DbContext mit dem man zumindest einmalig den Code für den Context und die Entities aus einer DB erstellen lassen kann.
    Nur für die Migrations gibt es aktuell noch nix und dafür muss man dann Änderungen quasi manuell machen. Aber mit einem Scaffold Projekt kann man sich zumindest einfach immer alles ziehen und dann nur hin und her kopieren.
    Generell scheint mir Code First auf jeden Fall besser, solange man keine richtig datenbanklastige Anwendung hat.
    Denn es gibt nicht ohne Grund DB Entwickler und die entwickeln einfach bessere Abfragen, Indizes usw. Auch wenn man das meisten theoretisch auch über EF Core setzen kann.
    Das ist meine Signatur und sie wird wunderbar sein!

    Mono schrieb:

    Man kann auch mit EF Core DB First umsetzen.
    Zumindest für den Anfang. Es gibt bei den Tools ein Scaffold DbContext mit dem man zumindest einmalig den Code für den Context und die Entities aus einer DB erstellen lassen kann.
    Nur für die Migrations gibt es aktuell noch nix und dafür muss man dann Änderungen quasi manuell machen. Aber mit einem Scaffold Projekt kann man sich zumindest einfach immer alles ziehen und dann nur hin und her kopieren.

    Stimmt. Gebe ich dir recht. Nur, ich für meinen Teil, wenn ich über solche Dinge spreche dann immer rein darüber was "OutOfTheBox" ohne Einsatz durch Drittanbieter-Software möglich ist.
    EF Core konzentriert sich eigentlich rein auf CodeFirst, was auch (meiner Meinung nach) gut ist.

    Mono schrieb:

    Denn es gibt nicht ohne Grund DB Entwickler und die entwickeln einfach bessere Abfragen, Indizes usw. Auch wenn man das meisten theoretisch auch über EF Core setzen kann.

    Nicht die meisten. ALLE! Oder kann man etwas nicht umsetzen. Da man ja einen SQL Befehl auch absetzen kann sollte ALLES machbar sein.

    Man muss mal unterscheiden. Das eine ist eine DB, das andere eine Anwendung. Dazwischen kann ein O/R Mapper hängen.
    Ob das jetzt z.b. NHibernate, EF6, EF Core oder sonst was ist sei jetzt mal egal. Fakt ist: Reiner und gut(!!) geschriebener SQL ist immer performanter und schneller. Das bedeutet aber nicht das dies immer der Fall ist. Ich habe bis jetzt echt SEHR SELTEN gut geschriebenen SQL gesehen welches dadurch performanter wäre als EF Core.

    Schaut man sich die Benchmarks mal genauer an kann man sehen das EF Core ohne Tracking genauso schnell ist wie manuelles Abrufen einer Abfrage mit manuellem mappen auf POCO Entitäten. Ob ich es also manuell mache und meine Klassen mit dem Ergebnis eines ADO.NEt DataReaders befülle is egal. EF Core ist wirklich gleich schnell. ABER wie schon gesagt. Selten jemanden gesehen der gutes SQL schreibt. Oft ist die Zeit nicht den SQL zu optimieren.
    Auch macht es keinen Spass. Wenn ich mir manche Querys nur mal ansehen. Mit LINQ eine Zeile Code was in 50-70 Zeilen SQL resultiert. Abgesehen davon das ich keine Compilerprüfung habe.

    Tja, und sollte es wirklich mal um performance gehen.... auch mit dem EF Core kann man einen SQL Befehl absetzen. Also auch hierfür ist gesorgt. EF Core kann seit der 1.1 (ich glaube die 1.1 war es) auch RAW-SQL Abfragen in Entitäten Mappen was EF 6 nicht konnte.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Ich beziehe mich da jetzt aber auf EFCore welches dies nicht mehr macht und ausserdem z.b. auch automatisches Batching beherrscht. Weiters sind in EFCore die Abfragen weit schöner da diese anders als in EF bis V6 den Provider überlassen werden. Aber das kann man alles nachlesen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Hey sorry bin zur Zeit einfach sehr busy.
    EF Core kann database first out-of-the box. Du brauchst halt die EFCore CLI.
    Für Codefirst brauchst ja auch das Migration Tool:
    docs.microsoft.com/en-us/ef/co…cellaneous/cli/powershell

    Da gibts ein Scaffold-DBContext was dir eine bestehende Datenbank ausliest und dir die Klassen baut.
    Sämtliche Änderungen sind dann aber halt etwas umständlich wenn man weiter database first fahren wöllte.

    Was wegfällt ist alles optische ala EDMX Designer usw.

    LG
    Das ist meine Signatur und sie wird wunderbar sein!