3 Gründe, Code First Design mit Entity Framework zu verwenden
1) Weniger Cruft, weniger Aufblähen
Die Verwendung einer vorhandenen Datenbank zum Generieren einer EDMX-Modelldatei und der zugehörigen Codemodelle führt zu einem riesigen Stapel automatisch generierten Codes. Sie werden gebeten, diese generierten Dateien niemals zu berühren, damit Sie nichts beschädigen oder Ihre Änderungen bei der nächsten Generation überschrieben werden. Der Kontext und der Initialisierer sind auch in diesem Durcheinander zusammengeklemmt. Wenn Sie Ihren generierten Modellen Funktionen hinzufügen möchten, z. B. eine berechnete schreibgeschützte Eigenschaft, müssen Sie die Modellklasse erweitern. Dies ist eine Anforderung für fast jedes Modell und Sie erhalten eine Erweiterung für alles.
Mit Code werden Ihre handcodierten Modelle zuerst zu Ihrer Datenbank. Die genauen Dateien, die Sie erstellen, generieren das Datenbankdesign. Es gibt keine zusätzlichen Dateien und es ist nicht erforderlich, eine Klassenerweiterung zu erstellen, wenn Sie Eigenschaften hinzufügen möchten oder was auch immer die Datenbank nicht wissen muss. Sie können sie einfach derselben Klasse hinzufügen, solange Sie der richtigen Syntax folgen. Sie können sogar eine Model.edmx-Datei generieren, um Ihren Code zu visualisieren, wenn Sie möchten.
2) Größere Kontrolle
Wenn Sie zuerst in die Datenbank gehen, sind Sie dem ausgeliefert, was für Ihre Modelle zur Verwendung in Ihrer Anwendung generiert wird. Gelegentlich ist die Namenskonvention unerwünscht. Manchmal sind die Beziehungen und Assoziationen nicht ganz das, was Sie wollen. In anderen Fällen verursachen nicht vorübergehende Beziehungen mit verzögertem Laden Chaos in Ihren API-Antworten.
Während es fast immer eine Lösung für Probleme bei der Modellgenerierung gibt, auf die Sie möglicherweise stoßen, bietet Ihnen der erste Code von Anfang an eine vollständige und fein abgestimmte Kontrolle. Sie können jeden Aspekt Ihrer Codemodelle und Ihres Datenbankdesigns bequem von Ihrem Geschäftsobjekt aus steuern. Sie können Beziehungen, Einschränkungen und Assoziationen genau angeben. Sie können gleichzeitig Eigenschaftszeichenbeschränkungen und Datenbankspaltengrößen festlegen. Sie können angeben, welche verwandten Sammlungen eifrig geladen oder überhaupt nicht serialisiert werden sollen. Kurz gesagt, Sie sind für mehr Dinge verantwortlich, haben aber die volle Kontrolle über Ihr App-Design.
3) Datenbankversionskontrolle
Dies ist eine große. Die Versionierung von Datenbanken ist schwierig, aber mit Code First- und Code First-Migrationen ist sie viel effektiver. Da Ihr Datenbankschema vollständig auf Ihren Codemodellen basiert, helfen Sie durch Versionskontrolle Ihres Quellcodes bei der Versionierung Ihrer Datenbank. Sie sind für die Steuerung Ihrer Kontextinitialisierung verantwortlich, die Ihnen dabei helfen kann, beispielsweise festgelegte Geschäftsdaten zu erstellen. Sie sind auch für die Erstellung der ersten Code-Migrationen verantwortlich.
Wenn Sie Migrationen zum ersten Mal aktivieren, werden eine Konfigurationsklasse und eine erste Migration generiert. Die anfängliche Migration ist Ihr aktuelles Schema oder Ihre Baseline v1.0. Ab diesem Zeitpunkt fügen Sie Migrationen hinzu, die mit einem Zeitstempel versehen und mit einem Deskriptor gekennzeichnet sind, um die Reihenfolge der Versionen zu erleichtern. Wenn Sie Add-Migration vom Paketmanager aus aufrufen, wird eine neue Migrationsdatei generiert, die alles enthält, was sich in Ihrem Codemodell automatisch geändert hat, sowohl in einer UP () - als auch in einer DOWN () -Funktion. Die UP-Funktion wendet die Änderungen auf die Datenbank an. Die DOWN-Funktion entfernt dieselben Änderungen für den Fall, dass Sie ein Rollback durchführen möchten. Darüber hinaus können Sie diese Migrationsdateien bearbeiten, um zusätzliche Änderungen wie neue Ansichten, Indizes, gespeicherte Prozeduren und andere Elemente hinzuzufügen. Sie werden zu einem echten Versionsverwaltungssystem für Ihr Datenbankschema.
