Wie könnte EF Code First Migration jemals als "gute" Programmierpraxis angesehen werden?

Question

In einer Einführung in das Entity Framework-Tutorial sehe ich, wie viel Zeit es kostet, Datenbank-Tabellen mit Code First Migrations zu erstellen und zu ändern. In Code First Migrations werden benutzerdefinierte Klassen, die einer DbContext-Unterklasse hinzugefügt wurden, zum erstmaligen Erstellen der entsprechenden Datenbanktabellen verwendet. Dann wird gezeigt, wie eine Änderung an einer dieser Klassen, wie beispielsweise das Hinzufügen einer neuen Eigenschaft, in die Datenbanktabelle geschoben werden kann. Hier ist meine aktuellen Überlegungen dazu:

All diese Fähigkeit zum Definieren von Klassen, erstellen Sie DB-Tabellen von ihnen, Änderungen vornehmen, Push-Änderungen an der Datenbank scheint auf Entwickler gerichtet, die Datenbanken und Datenbank-Syntax nicht kennen. Ich würde argumentieren, dass, wenn ein Entwickler Datenbankdesign und Syntax nicht gut genug kennt, um diese Dinge in der nativen Umgebung und Syntax des Zieldatenbankservers zu tun, er es überhaupt nicht tun sollte; vor allem nicht in einer Umgebung, die die Details abstrahiert. Um es anders auszudrücken, es ist viel einfacher und übersichtlicher, nur die nativen db-Werkzeuge und -Techniken zum Erstellen der Datenbankobjekte zu verwenden.

Meine Frage ist, warum würde ein professioneller Entwickler oder ein Entwicklungsladen jemals diese Techniken für irgendeine Form der Datenbankobjekterstellung oder -wartung verwenden?

Ich sollte wahrscheinlich hinzufügen, dass ich diese Frage nicht stelle, um diejenigen, die dies verwenden, anzuklagen. Ich stelle die Frage, denn wenn ich etwas verpasse, möchte ich wissen, was es ist.

Answer 1

Erstens ist es nicht erforderlich, Migrationen mit Code First zu verwenden. Sie könnten ein Datenbankprojekt oder eine der Methoden verwenden, die Chris hier erwähnt: http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1

Ihre Frage scheint mehr über den Code First Workflow, von dem es viele Diskussionspunkte gibt. Die Objekte vor die relationale Datenbank zu stellen, ist etwas, mit dem sich viele erfahrene Entwickler nicht auskennen.

„scheint für Entwickler gedacht, die nicht wissen Datenbanken und Datenbank Syntax“

- EF Wikipedia-Eintrag heißt es schön: „The Entity Framework ermöglicht es Entwicklern, mit Daten in Form von Arbeit domänenspezifische Objekte und Eigenschaften wie Kunden und Kundenadressen, ohne sich mit den zugrunde liegenden Datenbanktabellen und -spalten, in denen diese Daten gespeichert sind, befassen zu müssen. Mit dem Entity Framework können Entwickler auf einer höheren Abstraktionsebene mit Daten arbeiten und datenorientierte Anwendungen mit weniger Code als in herkömmlichen Anwendungen erstellen und verwalten. "

" Warum sollte ein professioneller Entwickler arbeiten? oder ein Entwicklungsgeschäft jemals diese Techniken für jede Form von Datenbank-Objekterstellung oder Wartung verwenden“

- Als professioneller Entwickler, Sie noch wissen müssen die Mieter von OOD (Containment, Zusammensetzung, etc.) und wenden SOLID-Prinzipien an. Mit beiden Workflow werden Sie immer noch mit der impedance mismatch.

butt heads gehen BTW, arbeite ich in einem Geschäft mit sehr strengen DBAs. Unser Team verwendet weiterhin EF mit Migrationen, aber wir verwenden die Techniken zur Erstellung von Skripts, um Skripts zur Aktualisierung des Schemas bereitzustellen. Ist es das richtige Werkzeug für jedes Geschäft oder Projekt? Nein. Tatsächlich haben wir Dapper als eine leichtere Gewichtsschicht betrachtet.