Varlık Özellikleri

Modelinizdeki her varlık türünün, EF Core'un veritabanından okuyup yazacağı bir özellik kümesi vardır. İlişkisel veritabanı kullanıyorsanız varlık özellikleri tablo sütunlarıyla eşlenir.

Dahil edilen ve dışlanan özellikler

Kural gereği, bir alıcı ve ayarlayıcıya sahip tüm genel özellikler modele dahil edilir.

Belirli özellikler aşağıdaki gibi dışlanabilir:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }

    [NotMapped]
    public DateTime LoadedFromDatabase { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Ignore(b => b.LoadedFromDatabase);
}

Sütun Adları

Kural gereği, ilişkisel veritabanı kullanılırken varlık özellikleri özelliğiyle aynı ada sahip tablo sütunlarıyla eşlenir.

Sütunlarınızı farklı adlarla yapılandırmayı tercih ediyorsanız, bunu aşağıdaki kod parçacığı gibi yapabilirsiniz:

Veri Açıklamaları

public class Blog
{
    [Column("blog_id")]
    public int BlogId { get; set; }

    public string Url { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.BlogId)
        .HasColumnName("blog_id");
}

Sütun veri türleri

İlişkisel veritabanı kullanırken, veritabanı sağlayıcısı özelliğin .NET türüne göre bir veri türü seçer. Ayrıca yapılandırılan maksimum uzunluk, özelliğin birincil anahtarın parçası olup olmadığı gibi diğer meta verileri de dikkate alır.

Örneğin, SQL Server özellikleri sütunlara, özellikleri ise sütunlara nvarchar(max)nvarchar(450) (veya anahtar olarak kullanılan özellikler için) eşlerDateTime.stringdatetime2(7)

Sütunlarınızı bir sütun için tam veri türünü belirtmek üzere de yapılandırabilirsiniz. Örneğin, aşağıdaki kod en uzunluğa sahip unicode olmayan bir dize olarak yapılandırılır Url ve Rating değerinin 2005 duyarlığı ve ölçeği ile ondalık olarak yapılandırılır2:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }

    [Column(TypeName = "varchar(200)")]
    public string Url { get; set; }

    [Column(TypeName = "decimal(5, 2)")]
    public decimal Rating { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>(
        eb =>
        {
            eb.Property(b => b.Url).HasColumnType("varchar(200)");
            eb.Property(b => b.Rating).HasColumnType("decimal(5, 2)");
        });
}

Maksimum uzunluk

Maksimum uzunluğu yapılandırmak, veritabanı sağlayıcısına belirli bir özellik için seçebileceğiniz uygun sütun veri türü hakkında bir ipucu sağlar. Uzunluk üst sınırı yalnızca ve byte[]gibi string dizi veri türleri için geçerlidir.

Dekont

Entity Framework, sağlayıcıya veri geçirmeden önce uzunluk üst sınırını doğrulamaz. Uygun olup olmadığını doğrulamak sağlayıcıya veya veri deposuna bağlı. Örneğin, SQL Server'ı hedeflerken maksimum uzunluğun aşılması, temel alınan sütunun veri türü fazla verilerin depolanmasına izin vermediğinden bir özel durumla sonuçlanır.

Aşağıdaki örnekte, en fazla 500 uzunluk yapılandırılması SQL Server'da tür nvarchar(500) sütunu oluşturulmasına neden olur:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }

    [MaxLength(500)]
    public string Url { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.Url)
        .HasMaxLength(500);
}

Duyarlık ve Ölçek

Bazı ilişkisel veri türleri duyarlık ve ölçek modellerini destekler; bunlar hangi değerlerin depolanabileceğini ve sütun için ne kadar depolama alanı gerektiğini denetler. Duyarlık ve ölçeklendirmeyi destekleyen veri türleri veritabanına bağımlıdır, ancak çoğu veritabanı decimal ve DateTime tür bu modelleri destekler. Özellikler için decimal duyarlık, sütunun içereceği herhangi bir değeri ifade etmek için gereken basamak sayısı üst sınırını ve ölçek de gereken en fazla ondalık basamak sayısını tanımlar. Özellikler için DateTime duyarlık, saniye kesirlerini ifade etmek için gereken maksimum basamak sayısını tanımlar ve ölçek kullanılmaz.

Dekont

Entity Framework, sağlayıcıya veri geçirmeden önce duyarlık veya ölçek doğrulaması yapmaz. Uygun şekilde doğrulamak sağlayıcıya veya veri deposuna bağlı. Örneğin, SQL Server'ı hedeflerken veri türündeki datetime bir sütun duyarlık ayarlanmasına izin vermezken, bir datetime2 sütun 0 ile 7 arasında duyarlık içerebilir.

Aşağıdaki örnekte özelliğin Score duyarlık 14 ve ölçek 2 olacak şekilde yapılandırılması SQL Server'da türünde decimal(14,2) bir sütun oluşturulmasına neden olur ve özelliğin LastUpdated duyarlık 3 olacak şekilde yapılandırılması türünde datetime2(3)bir sütuna neden olur:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }
    [Precision(14, 2)]
    public decimal Score { get; set; }
    [Precision(3)]
    public DateTime LastUpdated { get; set; }
}

Ölçek, önce duyarlık tanımlamadan hiçbir zaman tanımlanmadığından ölçeği tanımlamak için Veri Ek Açıklaması şeklindedir [Precision(precision, scale)].

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.Score)
        .HasPrecision(14, 2);

    modelBuilder.Entity<Blog>()
        .Property(b => b.LastUpdated)
        .HasPrecision(3);
}

Önce duyarlık tanımlanmadan ölçek hiçbir zaman tanımlanmadığından, ölçeği tanımlamak için Fluent API'si olur HasPrecision(precision, scale).

Unicode

Bazı ilişkisel veritabanlarında Unicode ve Unicode olmayan metin verilerini temsil eden farklı türler vardır. Örneğin, SQL Server'da, nvarchar(x) UTF-16'da Unicode verilerini temsil etmek için kullanılırkenvarchar(x), Unicode olmayan verileri temsil etmek için kullanılır (ancak SQL Server UTF-8 desteğindeki notlara bakın). Bu kavramı desteklemeyen veritabanları için bunu yapılandırmanın hiçbir etkisi yoktur.

Metin özellikleri varsayılan olarak Unicode olarak yapılandırılır. Bir sütunu unicode olmayan olarak aşağıdaki gibi yapılandırabilirsiniz:

Veri Açıklamaları

public class Book
{
    public int Id { get; set; }
    public string Title { get; set; }

    [Unicode(false)]
    [MaxLength(22)]
    public string Isbn { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Book>()
        .Property(b => b.Isbn)
        .IsUnicode(false);
}

Gerekli ve isteğe bağlı özellikler

Özelliğin içermesi nullgeçerliyse isteğe bağlı olarak kabul edilir. Bir özelliğe atanacak geçerli bir değer değilse null , gerekli bir özellik olarak kabul edilir. İlişkisel veritabanı şemasına eşlenirken, gerekli özellikler null atanamaz sütunlar olarak, isteğe bağlı özellikler de null atanabilir sütunlar olarak oluşturulur.

Kurallar

Kural gereği, .NET türü null içerebilen bir özellik isteğe bağlı olarak yapılandırılırken, .NET türü null içeremeyen özellikler gerektiği gibi yapılandırılır. Örneğin, .NET değer türlerine (int, decimal, bool, vb.) sahip tüm özellikler gerektiği gibi yapılandırılır ve null atanabilir .NET değer türlerine (int?, decimal?, bool?, vb.) sahip tüm özellikler isteğe bağlı olarak yapılandırılır.

C# 8, başvuru türlerinin null içermesi veya içermemesi için geçerli olup olmadığını gösteren, başvuru türlerinin açıklama eklemesine olanak tanıyan null atanabilir başvuru türleri (NRT) adlı yeni bir özellik kullanıma sunuldu. Bu özellik yeni proje şablonlarında varsayılan olarak etkindir, ancak açıkça kabul edilmediği sürece mevcut projelerde devre dışı kalır. Null atanabilir başvuru türleri EF Core'un davranışını aşağıdaki şekilde etkiler:

• Boş değer atanabilir başvuru türleri devre dışı bırakılırsa, .NET başvuru türlerine sahip tüm özellikler kurala göre isteğe bağlı olarak yapılandırılır (örneğin, string).
• Null atanabilir başvuru türleri etkinleştirilirse, özellikler .NET türlerinin C# null atanabilirliğine göre yapılandırılır: string? isteğe bağlı olarak yapılandırılır, ancak string gerektiğinde yapılandırılır.

Aşağıdaki örnekte, null atanabilir başvuru özelliği devre dışı bırakılmış ve etkin olan gerekli ve isteğe bağlı özelliklere sahip bir varlık türü gösterilmektedir:

NRT olmadan (varsayılan)

public class CustomerWithoutNullableReferenceTypes
{
    public int Id { get; set; }

    [Required] // Data annotations needed to configure as required
    public string FirstName { get; set; }

    [Required] // Data annotations needed to configure as required
    public string LastName { get; set; }

    public string MiddleName { get; set; } // Optional by convention
}

NRT ile

public class Customer
{
    public int Id { get; set; }
    public string FirstName { get; set; } // Required by convention
    public string LastName { get; set; } // Required by convention
    public string? MiddleName { get; set; } // Optional by convention

    // Note the following use of constructor binding, which avoids compiled warnings
    // for uninitialized non-nullable properties.
    public Customer(string firstName, string lastName, string? middleName = null)
    {
        FirstName = firstName;
        LastName = lastName;
        MiddleName = middleName;
    }
}

C# kodunda ifade edilen null atanabilirliği EF Core'un modeline ve veritabanına akıttığı ve aynı kavramı iki kez ifade etmek için Fluent API veya Veri Ek Açıklamaları kullanımını gizlediğinden, null atanabilir başvuru türlerinin kullanılması önerilir.

Dekont

Mevcut bir projede null atanabilir başvuru türlerini etkinleştirirken dikkatli olun: Önceden isteğe bağlı olarak yapılandırılan başvuru türü özellikleri, boş değer atanacak şekilde açıkça açıklama eklenmediği sürece artık gerektiği gibi yapılandırılacaktır. İlişkisel veritabanı şemasını yönetirken, bu durum veritabanı sütununun null atanabilirliğini değiştiren geçişlerin oluşturulmasına neden olabilir.

Boş değer atanabilir başvuru türleri ve bunların EF Core ile nasıl kullanılacağı hakkında daha fazla bilgi için bu özelliğin ayrılmış belgeler sayfasına bakın.

Açık yapılandırma

Kurala göre isteğe bağlı olacak bir özellik aşağıdaki gibi gerekli olacak şekilde yapılandırılabilir:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }

    [Required]
    public string Url { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.Url)
        .IsRequired();
}

Sütun harmanlamaları

Harmanlama, metin sütunlarında tanımlanabilir ve bunların nasıl karşılaştırılıp sıralandığını belirler. Örneğin, aşağıdaki kod parçacığı bir SQL Server sütununu büyük/küçük harfe duyarlı olmayacak şekilde yapılandırıyor:

modelBuilder.Entity<Customer>().Property(c => c.Name)
    .UseCollation("SQL_Latin1_General_CP1_CI_AS");

Veritabanındaki tüm sütunların belirli bir harmanlama kullanması gerekiyorsa, bunun yerine harmanlamayı veritabanı düzeyinde tanımlayın.

Harmanlamalar için EF Core desteği hakkında genel bilgiler harmanlama belgeleri sayfasında bulunabilir.

Sütun açıklamaları

Veritabanı sütununda ayarlanan ve şemanızı veritabanında belgelemenize olanak sağlayan rastgele bir metin açıklaması ayarlayabilirsiniz:

Veri Açıklamaları

public class Blog
{
    public int BlogId { get; set; }

    [Comment("The URL of the blog")]
    public string Url { get; set; }
}

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .Property(b => b.Url)
        .HasComment("The URL of the blog");
}

Sütun sırası

Varsayılan olarak, Migrations ile bir tablo oluştururken EF Core birincil anahtar sütunlarını önce sıralar, ardından varlık türünün ve sahip olunan türlerin özelliklerini ve son olarak temel türlerdeki özellikleri sıralar. Ancak, farklı bir sütun sırası belirtebilirsiniz:

Veri Açıklamaları

public class EntityBase
{
    [Column(Order = 0)]
    public int Id { get; set; }
}

public class PersonBase : EntityBase
{
    [Column(Order = 1)]
    public string FirstName { get; set; }

    [Column(Order = 2)]
    public string LastName { get; set; }
}

public class Employee : PersonBase
{
    public string Department { get; set; }
    public decimal AnnualSalary { get; set; }
}

Fluent API'si, farklı özelliklerdeki öznitelikler aynı sıra numarasını belirttiğinde çakışmaları çözmek de dahil olmak üzere özniteliklerle yapılan sıralamayı geçersiz kılmak için kullanılabilir.

Fluent API

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Employee>(x =>
    {
        x.Property(b => b.Id)
            .HasColumnOrder(0);

        x.Property(b => b.FirstName)
            .HasColumnOrder(1);

        x.Property(b => b.LastName)
            .HasColumnOrder(2);
    });
}

Genel durumda çoğu veritabanının yalnızca tablo oluşturulduğunda sütunları sıralamayı desteklediğini unutmayın. Bu, sütun sırası özniteliğinin mevcut bir tablodaki sütunları yeniden sıralamak için kullanılamayacağı anlamına gelir.