Entfernen der erforderlichen Eigenschaften aus dem EF-Modell, da es schreibgeschützt ist

Question

Ich habe ein Projekt mit einem kleinen Datenmodell, das EF-Modelle schreibgeschützt verwendet.

Ich möchte nicht die vollständige Reihe von Spalten in den Modellen, aber ich muss sie haben, wenn sie nicht Nullable sind und keine Standardwerte haben.

Wie kann ich solche Spalten vermeiden? Kann ich EF in einen schreibgeschützten Modus im Datenmodell einfügen, mit dem ich die Spalten aus den Entitäten entfernen kann?

Der Grund, warum ich dies tun möchte, ist, weil die Spalten in meinen Datenmodellen nur auf das reduzieren, was ich brauche, die Spalten reduzieren, die das Modell in Abfragen zurückgeben muss, und ich das Risiko reduzieren, meine Datenkonsumenten zu brechen Änderungen.

EDIT: Mein Schema hat Tabellen mit NOT NULL Spalten ohne Standardwerte. Soweit ich das beurteilen kann, muss ich diese Spalten in meiner edmx enthalten. In meiner Situation habe ich nur Lese-Kontext, so dass ich nicht möchte, dass diese Spalten in meiner Edmx enthalten sind.

Wenn ich verhindern kann, dass die Spalten im Datenmodell enthalten sind, kann ich viele Probleme vermeiden, die sich aus der Änderung des Schemas ergeben. Die einzige Lösung, die ich bisher gefunden habe, ist, das Datamodell zu erstellen, indem ich auf eine "falsche" Datenbank zeige, die keine Spalten enthält!

Answer 1

Suchen Sie nach Daten Annotation [NotMapped]?

Wenn Sie es in einer Eigenschaft innerhalb des Modells verwenden, wird es nicht an die Datenbank übergeben.

Answer 2

Laut MSDN ist ein QueryView genau für das von Ihnen beschriebene Szenario konzipiert.

Das QueryView Element in Zuordnung Spezifikationssprache (MSL) eine Nur-Lese-Zuordnung zwischen einem Entitätstyp oder Vereinigung im konzeptionellen Modell und ein Tisch in der zugrunde liegenden Datenbank.

Sie können Query Views definieren die folgenden Szenarien zu aktivieren:

definieren eine Entität im konzeptionellen Modell, das nicht alle Eigenschaften der Entität im Speichermodell enthält. Dies schließt Eigenschaften ein, die keine Standardwerte haben und null Werte nicht unterstützen.

... (mehr Szenarien auf der Seite)

Sie können die Designer für diese, aber es sieht einfach genug von Hand zu tun. Hier

ist ein Link zu der entsprechenden MSDN-Dokumentation:
https://msdn.microsoft.com/en-us/library/cc716798(v=vs.100).aspx

Im Fall, dass Link tot geht, eine Suche nach QueryView MSL.

Answer 3

Wenn Sie Code-First anstelle der Datenbank verwenden möchten, könnte dies zunächst sehr einfach sein.

Nehmen Sie zum Beispiel Microsofts Beispieldatenbank School. Es hat eine Tabelle Course mit einer Anzahl von Pflichtfeldern.Aber es ist möglich, eine Klasse mit nur einer kleinen Teilmenge dieser Felder abzubilden ...

class Course 
{ 
    public int CourseID { get; private set; } 
    public string Title { get; private set; } 
} 

... dieser Tabelle ignoriert erforderlichen Felder Credits und DepartmentID.

Das fließend Mapping in dem OnModelCreating Überschreibung Kontext ist

modelBuilder.Entity<Course>().HasKey(a => a.CourseID); 
modelBuilder.Entity<Course>().Property(a => a.CourseID) 
        .HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity); 

Wie Sie sehen, habe ich die Eigenschaften mit einem privaten Setter definiert. EF hat damit keine Probleme und kommuniziert jedem Verbraucher des Modells, dass das Modell schreibgeschützt ist.

Hinzu kommt man auch nicht-Schlüsseleigenschaften wie Computed Karte könnte:

modelBuilder.Entity<Course>().Property(a => a.Title) 
      .HasDatabaseGeneratedOption(DatabaseGeneratedOption.Computed); 

Jetzt versehentlich jede Eigenschaft Wert zu aktualisieren, es ist unmöglich, weil EF einfach nicht sie in UPDATE Aussagen enthalten.

Answer 4

Ich kann viele Probleme verhindern, die sich aus der Änderung des Schemas ergeben.

Das fällt letztlich auf Datenbank-Design zurück. Die Datenbank muss für das von Ihnen präsentierte Aktualisierungsszenario anders gestaltet sein. Das Herausziehen der genannten Spalten in eine NULL-fähige FK-bezogene Tabelle wäre eine praktikable Option ohne zukünftige Änderungen, die für EF erforderlich sind.

aber ich muss sie haben, wenn sie nicht Nullable sind und keine Standardwerte haben.

EF nur pflichtgemäß berichtet, was in der Datenbank als durch sein Design ist.

Jede Schemaänderung kann sich auf eine Reihe von Faktoren auswirken, z. B. neue Integritätsbedingungen, Trigger und allgemeine Tabellenänderungen. Spalten in einem Designer zu verstecken und dann zu hoffen, dass es auf einer anderen Schema-d Datenbank funktioniert, ist nicht klug.

Ich habe persönlich in nicht synchronisierten EF Design-Modellen gelaufen und es gibt logische Fehler, die den Code auf seltsame Weise beeinflussen können.

Ich reduziere das Risiko, meine Datenkonsumenten zu brechen, wenn sich das Schema ändert.

Genau wie sind diese Verbraucher Zugriff auf die Daten?

Jeder echte Verbraucher sollte entweder eine Webservice- oder Factory-Pattern-Zugriffsebene durchlaufen, in der die Daten nur als Datenobjekt (e) Interface zurückgegeben werden sollen. Wenn sich die Datenbank oder das Schema ändert, ändert sich die zurückgegebene (n) Schnittstelle (n) daher nicht; daher bricht dieses Schema-Update keinen Verbrauchersafe hinter einer Schnittstelle ab, ungeachtet des konkreten Objekts, das verwendet wird.

Es ist nicht die Antwort, die Sie wollen, aber dies bietet zwei Alternativen zum Erreichen des gleichen Ziels.

Answer 5

Sie können dieses Problem auch beheben, indem Sie die unerwünschten Eigenschaften aus dem Abschnitt des EDMX-Speichermodells entfernen.