Entity Framework 4 CTP 5 – Die Prioritäten zwischen manuellen Mapping und den DataAnnoations
Die neue Funktionalität der DataAnnoations ist sehr nützlich. Doch wie verhält sich das Mapping, wenn ein manuelles Mapping über den Model-Builder vorgenommen wird und die DataAnnoations verwendet werden?
Es gibt bekanntlich immer Sonderfälle, bei denen es Abweichungen zum Datenmodell geben kann. Einerseits steht dann die Überlegung im Raum, ob nicht zuerst mit der Datenbank begonnen werden soll. Diese Frage beantwortet sich meist von selbst, wenn für das Projekt alle Stakeholder ermittelt und befragt worden sind.
Aber betrachten wir die Sonderfälle bei der codezentrierten Anwendungsentwicklung. Es kann Szenarien geben, da soll es möglich sein auf Basis der Metadatenklassen unterschiedliche Validierungsoptionen zu definieren. Im verwende dabei das Beispiel aus dem ersten Beitrag zu den DataAnnotations.
Der Code der Customer-Klasse und die DataAnnotations sind dabei wie folgt angelegt:
Customer-Klasse (C#)
[MetadataType(typeof(CustomerMetadata))]
public class Customer
{
public int Id { get; internal set; }
public string Name { get; set; }
public string Street { get; set; }
public string Postalcode { get; set; }
}
Metadaten-Klasse für Customer
public class CustomerMetadata
{
[StringLength(150)]
[Required]
public object Name { get; set; }
[StringLength(100, ErrorMessage = "The street name is too long.")]
[Required(AllowEmptyStrings = false, ErrorMessage = "The street name is required.")]
public object Street { get; set; }
[StringLength(5, ErrorMessage = "The postal code is too long.")]
[Required(AllowEmptyStrings = false, ErrorMessage = "The postal code is required.")]
[RegularExpression("^[0-9]{4,5}$", ErrorMessage = "The postal code is not valid.")]
public object Postalcode { get; set; }
}
Auf Datenbankebene soll es jedoch folgende Unterschiede geben:
- Die Eigenschaft Name soll eine Feldlänge von 200 Zeichen haben und optional sein
- Die Eigenschaft Postalcode soll eine Feldlänge von 30 Zeichen haben und ebenfalls optional sein
Also geht es nun darum, die manuelle Konfiguration für die abweichenden Eigenschaften zu erstellen. Dazu wird zuerst eine Konfigurationsklasse angelegt (kann auch direkt in der Methode OnModelCreating erfolgen).
Customer Konfigurationsklasse (C#)
internal class CustomerConfig : System.Data.Entity.ModelConfiguration.EntityTypeConfiguration<Customer>
{
public CustomerConfig()
{
this.Property(x => x.Name)
.HasMaxLength(200)
.IsVariableLength()
.IsUnicode()
.IsOptional();
this.Property(x => x.Postalcode)
.HasMaxLength(30)
.IsVariableLength()
.IsUnicode()
.IsOptional()
.HasColumnName("PLZ");
}
}
In dieser Konfigurationsklasse werden die Unterschiede zu den DataAnnotations definiert. Anschliessend wird diese Konfigurationsklasse dem Model-Builder hinzugefügt.
Konfiguration im DbContext (C#)
public class TestContext : DbContext
{
public DbSet<Customer> Customers
{
get;
set;
}
protected override void OnModelCreating(System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Configurations.Add(new CustomerConfig());
}
}
Auf Datenbankebene ändert sich gemäss der Konfiguration folgendes:
- Die Spalte Name hat eine Länge von 200 Zeichen und darf NULL sein
- Die Eigenschaft Postalcode hat den Namen PLZ, darf NULL sein und hat eine Feldlänge von 30 Zeichen
- Nicht definierte Eigenschaften in der Konfiguration erhalten die Definitionen gemäss der DataAnnotations

- Abbildung 1 Erstellte Tabelle mit manuellen Konfigurationseigenschaften
Somit wird ersichtlich, dass die manuelle Konfiguration einzelner Eigenschaften eine höhere Priorität einnehmen als die DataAnnotations.
- 0 Kommentar(e)


Mein Kommentar