DBML Anpassung vs Regeneration
Ich habe eine Datenbank mit vielen definierten Fremdschlüsselbeziehungen. Wenn ich einfach jede Tabelle, die an diesen FK-Verbindungen beteiligt ist, in den DBML-Editor ziehe, um die DBML-Datei maschinell zu generieren, werden diese alle als Zuordnungen dargestellt.
Von hier aus kann ich Änderungen an diesen Assoziationen vornehmen: Ich möchte vielleicht, dass das übergeordnete Ende der Assoziation internal ist und nicht public , so dass ein JSON-Serialisierer (wie gesagt) nicht zyklisch abgefangen wird Verweise; oder in einer Verbindung zwischen den Tabellen Form und FormAnswer möchte ich vielleicht, dass die Kind-Eigenschaft Answers genannt wird, anstatt die vom Computer generierte FormAnswers .
Wenn nun der Datenbankentwurf geändert wird und ich die DBML aktualisieren möchte, um diese Änderung widerzuspiegeln, müssen diese Anpassungen dazu führen, dass ich jede einzelne Änderung aufspüren und manuell aktualisieren muss (Eigenschaft hinzufügen, Quelle und Quelle festlegen) Datentyp, C # -Datentyp ...)
Dies kann ein ziemlich langwieriger Prozess sein; Ich frage, ob es eine Möglichkeit gibt, dies zu automatisieren.
1. Kann ich diese Änderungen auf dem SQL Server widerspiegeln?
Die ideale Lösung scheint zu sein, wenn es irgendeinen Weg gäbe, diese Spezifikationen direkt in den SQL Server-Datenbankdiagrammen zu machen, so dass die DBML-Datei vollständig regeneriert werden kann (alles löschen und auf den DBML-Editor ziehen) von neuem) würde mit genau dem gleichen Ergebnis kommen.
Ich vermute, dass ich bereits über das Obige Bescheid wissen würde, wenn es machbar wäre, würde ich mich gerne damit abfinden:
2. Kann ich diese Änderungen in eine eigene Klasse extrahieren?
Da alle Linq to SQL-Entitäten als partielle Klassen generiert werden, dachte ich eine Weile, dass ich vielleicht eine neue Datei erstellen könnte, die ich manuell bearbeite, zu der ich alle Änderungen wie die erwähnten kopieren könnte / p>
Also, wann immer ich eine Assoziation geändert habe, würde ich den Code designer.cs durchsuchen, die modifizierte Assoziation ausschneiden und sie in meine eigene Datei einfügen. Nach der Neugenerierung würde ich Compilerfehler für alle Duplikate erwarten und diese Verknüpfungen leicht aus der DBML überspringen und entfernen. Das Problem hierbei ist, dass die Assoziationen nur Eigenschaften mit Attributen zu sein scheinen. Wenn Form eine Eigenschaft namens Answers hat und der DBML-Generator versucht, eine Eigenschaft namens FormAnswers zu erstellen, würde das resultierende Form -Objekt einfach beide Eigenschaften haben, was nicht das ist, was ich will.
Hat jemand mit einer dieser Lösungen etwas Glück gehabt? Oder wenn Sie einen anderen Weg kennen, um mit dem Problem umzugehen, bin ich offen für Vorschläge.
3 Antworten
Ich habe ein Add-In für VS (2008, 2010, 2012 und 2013) , das Ihnen hier weiterhelfen kann . Es fügt DB & lt; = & gt; DBML-Synchronisierung und bietet eine Reihe von Einstellungen, mit denen Sie steuern können, welche Art von Änderungen an der Synchronisierung vorgenommen werden, sowie "Ausschlusslisten", mit denen Sie einzelne Tabellen / Ansichten / Mitglieder / FKs als Elemente "ohne Berührung" markieren können.
Wie für die FK = & gt; Assoziationsproblem, das Sie erwähnen: Mit den Synchronisierungsoptionen können Sie alle oder einzelne untergeordnete Navigationseigenschaften ausschließen Um zirkuläre Referenzen zu vermeiden, die Probleme beim Serialisieren von Entitätsobjekten verursachen können.
Sie können das Add-In von Ссылка herunterladen, wenn Sie es für eine Testdrehung verwenden möchten.
Ich habe keine Möglichkeit gefunden, meine DBML basierend auf Änderungen an der Datenbank automatisch zu aktualisieren, ohne die gesamte Arbeitsfläche zu löschen und die Elemente erneut zu ziehen. Und wie du sagst, werden die FKs alle umbenannt, was nervig ist.
DBMLs sind im XML-Format und ich habe oft festgestellt, dass es schneller und einfacher ist, das XML (Open With ...) zu bearbeiten, wenn die Änderungen der Hauptdatenbank abgeschlossen sind, und die Änderung dort wie parallel vorzunehmen zu dem Erstellungsskript, das ich als Teil meines Projekts aufbewahre.
Dann erstellen Sie neu, oder führen Sie einfach Custom Tool aus, um die Änderungen an den CS-Dateien neu zu generieren.
Das war in VS 2008, nicht sicher, ob es noch eine Herausforderung in 2010 ist.
HTH
Jeder Update-Befehl fehlt im Linq-To-Sql-Designer vollständig. Also ich denke, Designer ist nicht in realen inkrementellen Projekt verwendbar. Es gibt drei Möglichkeiten, dieses Problem zu lösen:
- Verwenden Sie nicht den Designer und Code für Ihre Zuordnungen
- Verwenden Sie den Designer nicht und schreiben Sie Ihre Mappings in XML . SqlMetal ist hilfreich für die erste Generierung.
- Erstellen Sie ein benutzerdefiniertes Tool, das Ihre Änderungen hinzufügt. Jedes Mal regenerierte das komplette Modell und führte dieses Tool aus.
Tags und Links .net linq-to-sql