次の方法で共有

エンティティのプロパティ

  • [アーティクル]

モデル内の各エンティティ型には一連のプロパティがあり、EF Core はデータベースから読み取りと書き込みを行います。 リレーショナル データベースを使用している場合、エンティティ プロパティはテーブル列にマップされます。

含まれるプロパティと除外されるプロパティ

規則 することにより、ゲッターとセッターを持つすべてのパブリック プロパティがモデルに含まれます。

特定のプロパティは、次のように除外できます。

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

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

列名

慣例により、リレーショナル データベースを使用する場合、エンティティ プロパティはプロパティと同じ名前のテーブル列にマップされます。

異なる名前で列を構成する場合は、次のコード スニペットのように構成できます。

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

    public string Url { get; set; }
}

列データ型

リレーショナル データベースを使用する場合、データベース プロバイダーはプロパティの .NET 型に基づいてデータ型を選択します。 また、構成された 最大長、プロパティが主キーの一部であるかどうかなど、他のメタデータも考慮されます。

たとえば、SQL Server プロバイダーは、DateTime プロパティを datetime2(7) 列にマップし、string プロパティを nvarchar(max) 列（またはキーとして使用されるプロパティの場合は nvarchar(450) 列）にマップします。

列の正確なデータ型を指定するように列を構成することもできます。 たとえば、次のコードでは、Url を unicode 以外の文字列として構成し、最大長は 200、Rating は 10 進数として、有効桁数は 5、小数点以下桁数は 2に設定します。

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; }
}

最大長

最大長を構成すると、特定のプロパティに対して選択する適切な列データ型に関するヒントがデータベース プロバイダーに提供されます。 最大長は、string や byte[]などの配列データ型にのみ適用されます。

手記

Entity Framework では、プロバイダーにデータを渡す前に、最大長の検証は行われません。 必要に応じて検証するのはプロバイダーまたはデータ ストアです。 たとえば、SQL Server を対象とする場合、基になる列のデータ型では余分なデータを格納できなくなるため、最大長を超えると例外が発生します。

次の例では、最大長 500 を構成すると、SQL Server に nvarchar(500) 型の列が作成されます。

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

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

精度とスケール

一部のリレーショナル データ型では、有効桁数ファセットとスケール ファセットがサポートされています。これらは、格納できる値と、列に必要なストレージの量を制御します。 データ型が有効桁数と小数点以下桁数をサポートするかどうかはデータベースに依存しますが、ほとんどのデータベースでは decimal 型と DateTime 型がこれらの特性をサポートしています。 decimal のプロパティでは、列に格納される値を表現するために必要な最大桁数が有効桁数によって定義され、また、小数点以下に必要な最大桁数が小数点以下桁数によって定義されます。 DateTime プロパティの場合、精度は秒の小数部を表すために必要な最大桁数を定義し、スケールは使用されません。

手記

Entity Framework では、プロバイダーにデータを渡す前に、精度やスケールの検証は行われません。 必要に応じて検証するのはプロバイダーまたはデータ ストアです。 たとえば、SQL Server を対象とする場合、datetime データ型の列では有効桁数を設定できませんが、datetime2 は 0 から 7 までの有効桁数を持つことができます。

次の例では、Score プロパティを有効桁数 14、小数点以下桁数 2 に設定すると、SQL Server に decimal(14,2) 型の列が作成され、LastUpdated プロパティを有効桁数 3 に構成すると、datetime2(3)型の列が作成されます。

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

スケールは、まず精度を定義しないと設定できませんので、スケールを定義するためのデータ注釈は [Precision(precision, scale)]です。

Unicode

リレーショナル データベースによっては、Unicode テキスト データと Unicode 以外のテキスト データを表すさまざまな型が存在します。 たとえば、SQL Server では、nvarchar(x) は UTF-16 で Unicode データを表すために使用されますが、varchar(x) は Unicode 以外のデータを表すために使用されます (ただし、SQL Server UTF-8 のサポートに関するメモを参照してください)。 この概念をサポートしていないデータベースの場合、これを構成しても効果はありません。

テキスト プロパティは、既定で Unicode として構成されます。 次のように、Unicode 以外の列を構成できます。

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

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

必須プロパティと省略可能なプロパティ

プロパティは、null の格納が有効である場合、省略可能と見なされます。 null がプロパティに割り当てられる有効な値でない場合は、必須プロパティと見なされます。 リレーショナル データベース スキーマにマッピングする場合、必須プロパティは null 非許容列として作成され、省略可能なプロパティは null 許容列として作成されます。

慣例

規則により、.NET 型に null を含めることができるプロパティは省略可能として構成されますが、.NET 型に null を含めることはできませんプロパティは、必要に応じて構成されます。 たとえば、.NET 値型 (int、decimal、boolなど) を持つすべてのプロパティが必要に応じて構成され、null 許容 .NET 値型 (int?、decimal?、bool?など) を持つすべてのプロパティが省略可能として構成されます。

C# 8 で導入された Null 許容参照型 (NRT) と呼ばれる新機能を使うと、参照型の値として Null が有効かどうかを示す注釈を設定できます。 この機能は、新しいプロジェクト テンプレートでは既定で有効になっていますが、明示的に選択しない限り、既存のプロジェクトでは無効のままです。 Null 許容参照型は、次のように EF Core の動作に影響します。

  • nullable 参照型が無効になっている場合、.NETの参照型を持つすべてのプロパティは、規約に従って省略可能として構成されます（たとえば、string）。
  • null 許容参照型が有効な場合、プロパティは .NET 型の C# の null 許容に基づいて構成されます。string? は省略可能として構成されますが、string は必要に応じて構成されます。

次の例では、必須プロパティと省略可能なプロパティを持つエンティティ型を、null 許容参照機能が無効な状態と有効な状態で示しています。

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
}

C# コードで表される null 値許容を EF Core のモデルとデータベースに流し、Fluent API またはデータ注釈を使用して同じ概念を 2 回表現することが難しくなるため、null 許容参照型を使用することをお勧めします。

手記

既存のプロジェクトで null 許容参照型を有効にする場合は注意が必要です。以前に省略可能として構成されていた参照型プロパティは、null 許容として明示的に注釈が付けされていない限り、必要に応じて構成されます。 リレーショナル データベース スキーマを管理すると、移行が生成され、データベース列の null 値が変更される可能性があります。

Null 許容参照型、そして EF Core におけるその使用方法について詳しくは、この機能専用のドキュメント ページを参照してください。

明示的な構成

規則によって省略可能なプロパティは、次のように必須に構成できます。

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

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

列の照合順序

照合順序は、テキスト列で定義し、比較および順序付け方法を決定できます。 たとえば、次のコード スニペットは、大文字と小文字を区別しないように SQL Server 列を構成します。

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

データベース内のすべての列で特定の照合順序を使用する必要がある場合は、代わりにデータベース レベルで照合順序を定義します。

照合順序の EF Core サポートに関する一般的な情報については、照合順序のドキュメント ページを参照してください。

列のコメント

データベース列に設定される任意のテキスト コメントを設定して、データベース内のスキーマを文書化できます。

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

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

列の順序

既定では、Migrationsを使用してテーブルを作成する場合、EF Core は最初に主キー列を並べ替え、次にエンティティ型と所有型のプロパティ、最後に基本型のプロパティを並べ替えます。 ただし、別の列の順序を指定できます。

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 を使用すると、異なるプロパティの属性で同じ順序番号が指定されている場合の競合の解決など、属性で行われた順序をオーバーライドできます。

一般的なケースでは、ほとんどのデータベースはテーブルの作成時にのみ列の順序付けをサポートします。 つまり、列の順序属性を使用して、既存のテーブルの列を並べ替えることはできません。