Ich beginne ein neues Projekt, das Entity Framework verwendet. Ich habe meine Optionen zum Erstellen der Datenbank untersucht und herausgefunden, dass Code-First-Migrationen am sinnvollsten sind (siehe unten, wenn Sie wissen wollen, warum). Durch Code-First-Migrationen kann ich auf beliebiges SQL zurückgreifen, was bedeutet, dass ich immer noch die volle Kontrolle habe. In der Praxis habe ich festgestellt, dass das Herunterfallen auf SQL für einige der üblichen Aufgaben schrecklich repetitiv ist.
Für meine Zwecke interessiert es mich nicht, dass Erweiterungen in der Migration providerunabhängig sind (die SQL, die ich einfüge, nicht). Im Migrations-Framework finde ich jedoch keine gute Nahtstelle oder Erweiterung, um solche Dinge hinzuzufügen.
Angenommen, ich möchte eine RowGuid-Spalte für die MS-SQL-Replikation angeben. Jedes Vorkommen hat die Form von
%Vor%Also schreibe ich statische Methoden, um etwas von der Redundanz loszuwerden
%Vor%-oder -
%Vor% Möglicherweise könnte eine dieser Erweiterungsmethoden auf DbMigration angewendet werden und auf sie durch this. zugreifen. Aber das sieht immer noch fehl am Platz aus:
Es ist nicht schrecklich, aber es fühlt sich immer noch wie ein Hack für mich an. Ich muss den Tabellennamen wiederholen, und ich muss sicherstellen, dass ich den generierten Spaltennamen richtig erkläre. Ich finde den Tabellennamen muss viel wiederholt werden, aber auch Spalten. Aber was ich wirklich versuche, zu tun, wenn ich auf die Tabellendeklaration setze, die gerade passiert ist, wo sowohl der Tabellenname als auch die Spaltennamen bekannt waren.
Ich konnte jedoch keinen guten Erweiterungspunkt finden, um die fließende Schnittstelle zu erweitern oder den Code für die ersten Migrationen auf eine Weise zu erweitern, die sich konsistent anfühlt. Fehle ich etwas? Hat jemand einen guten Weg gefunden, dies zu tun?
Einige Gründe, warum ich in dieser Situation bin:
Ich mochte die aus einer Reihe von Gründen scheinbar nicht übliche Lösung für die Verwendung allgemeiner Common-Attribute-Lösungen, um auf Nicht-Mapping-Datenbanken hinzuweisen, aber am stärksten, weil sie nicht automatisch von Migrationen übernommen werden, was zusätzliche Wartung bedeutet. Modell-erste Lösungen waren out, weil sie nicht die volle Kontrolle über die Datenbank geben. Database-First war wegen der Kontrolle ansprechend; Es verfügt jedoch nicht über die Standardfunktion für die Änderungsverwaltung, die von Code-First Migrations bereitgestellt wird. Daher schienen Code-First Migrations ein Gewinner zu sein, da [code-first] modellgesteuerte Änderungen automatisch sind und es bedeutete, dass es nur eine Sache zu pflegen gab.
Ich habe eine Lösung gefunden, obwohl ich nicht sicher bin, ob es gut ist. Ich musste ein wenig tiefer in das Kaninchenloch gehen, als ich es wollte, und es ist nicht wirklich ein Verlängerungspunkt.
Es erlaubt mir, Aussagen wie:
zu schreiben %Vor%Ich mag nicht:
Ich denke nur darüber nach, es hier zu verwenden, weil:
Keine generische Lösung, aber Sie können von einer abstrakten / Interface-Klasse erben. Dazu müssten einige Code-Änderungen, aber es ist einigermaßen sauber.
Ich habe dieses Muster verwendet, um meine Audit-Spalten (UpdatedBy, UpdateDate usw.) für alle Tabellen zu definieren.
Tags und Links sql c# entity-framework entity-framework-5 code-first-migrations