Was ist der Vorteil von CodeFirst over Database First?

8

Ich habe mir einige Videos und Tutorials für EF 4.1 angeschaut, und ich verstehe keinen Vorteil von CodeFirst (außer einige, wenn DB 3-4 Tabellen sehr klein ist und ich faul bin, DB zuerst zu erstellen).

Meistens ist der beste Ansatz bisher, Datenbank in einem Datenbank-Editor zu erstellen, der sicher schneller ist als das Bearbeiten im Entity Model und EF alle Beziehungen aufgreift und Assoziationen korrekt erstellt. Ich weiß, dass es Herausforderungen in der Namenskonvention gibt, aber ich finde es sehr verwirrend, Code First zu verwalten, da alles wie Code aussieht und es zu viel Code ist.

Was kann CodeFirst tun und Db kann das zuerst nicht?

    
Akash Kava 02.07.2011, 10:19
quelle

4 Antworten

17

CodeFirst kann nichts tun, was die DB zuerst nicht kann. Am Ende des Tages verwenden beide das Entity Framework.

Die wichtigsten Vorteile von codefirst sind:

  • Entwicklungsgeschwindigkeit - Sie müssen sich keine Gedanken über die Erstellung einer Datenbank machen, die Sie gerade programmieren. Gut für Entwickler, die aus einem Programmierhintergrund ohne viel DBA-Erfahrung kommen. Es hat auch automatische Datenbankaktualisierungen, so dass bei jeder Modelländerung die Datenbank automatisch aktualisiert wird.
  • POCOs - Der Code ist viel sauberer Sie nicht mit viel automatisch generiertem Code enden. Sie haben die volle Kontrolle über jeden Ihrer Klassen.
  • Einfach - Sie haben kein edmx-Modell zum Aktualisieren oder Verwalten von

Weitere Informationen finden Sie unter Code-First vs Model / Database -erste und hier Code-First oder Database-First, wie wählt man?

    
Daveo 02.07.2011, 10:31
quelle
7

Ausgehend von einem DataCentric-Ansatz werde ich es immer seltsam finden, dass die Leute es gerne in einem Code-First-Ansatz schaffen. Wenn ich meine Datenbank entwerfe, denke ich bereits darüber nach, was jede der Tabellen ist, als wären sie sowieso Klassen. Wie sie sich verbinden und wie die Daten fließen. Ich kann das ganze System durch die Datenbank abbilden.

Ich habe immer gelernt, dass du von Grund auf arbeitest, deine Grundlagen richtig machst und alles andere folgt. Ich erstelle viele, viele verschiedene Systeme für viele verschiedene Firmen und die Geschwindigkeit, die ich dafür verwende, basiert auf der Tatsache, dass ich, sobald ich ein starkes Datenbankmodell habe, meinen benutzerdefinierten Code-Generator ausführe, der die Ansichten / Stored Procedures erstellt sowie meinen Controller / BusinessLayer / DataLayer für mich, Setzen Sie all diese zusammen und alles, was ich tun muss, ist das Frontend zu erstellen.

Wenn ich zuerst das gesamte System in Code erstellen müsste, um die Datenbank zu generieren, sowie alle anderen Elemente, dann würde ich es viel länger dauern. Ich sage nicht, dass ich in irgendeiner Hinsicht recht habe, und ich bin mir sicher, dass es wahrscheinlich schnellere und erfahrenere Wege zur Entwicklung von Systemen gibt, aber bis jetzt habe ich noch keine gefunden.

Danke, dass du mich sprechen lässt, und ich hoffe, dass meine Ansichten ein wenig geholfen haben.

    
user155140 11.07.2014 20:06
quelle
2

Die Migration wurde in EntityFramework 4.3 für CodeFirst aktiviert Sie können Änderungen am Modell problemlos nahtlos in die Datenbank übernehmen Referenz 1

detailliertes Video: Complete Reference Video

    
saianirudh 23.02.2012 20:23
quelle
1

Nun, es hängt von Ihrem Projekt ab. Ich werde versuchen, eine Synthase einige Ideen zu machen:

  • Sie haben die vollständige Kontrolle über die Entitätsklassen. Sie werden nicht mehr generiert, Sie müssen keine T4-Vorlagen aktualisieren oder Teilklassen verwenden ...
  • Das EDMX-Modell verschwindet in EF7 zugunsten des CodeFirst-Modells. Denken Sie also daran, wenn Sie nach EF migrieren möchten oder in naher Zukunft Projekte starten, die EF7 verwenden könnten.
  • Einfachere Zusammenführung für den Fall, dass mehrere Entwickler am Modell arbeiten +/- Annotationen und Mapping sollten manuell vorgenommen werden. Ich würde sagen, Code-Ansatz scheint leichter (weniger aufgebläht) und wir können die Dinge einfach halten (visuelles Modell könnte unerwünschte Komplexität verbergen). Offen für Fluent API.
  • Sie können das Modell weiterhin über Power Tools anzeigen, das Modell ist jedoch schreibgeschützt. Jede Änderung am Modell sollte manuell vorgenommen werden (sogar die ursprünglichen Entitäten können von Grund auf neu generiert werden). Sie haben keine Teilmodelle (Diagramme), aber unsere Modelle sollten klein genug sein.
  • Es scheint, dass die Datenbank zuerst besser in SPs und Funktionsergebnisse integriert ist (einige Verbesserungen wurden in EF6 gemacht)
Mihai Bejenariu 10.09.2015 08:14
quelle