4

ここの例のように、典型的な情報（Id、Name、Street、City）を含むUsersというテーブルがあるとします。

http://weblogs.asp.net/manavi/archive/2010/12/11/entity-association-mapping-with-code-first-part-1-one-to-one-associations.aspx。

とりわけ、この記事は次のように述べています。

「CodeFirstには、一連の規則に基づいて機能する複合型検出の概念があります。規則は、Code Firstが主キーを推測できないクラスを検出し、データアノテーションまたは流暢なAPIを介して主キーが登録されない場合です。 、その場合、型は複合型として自動的に登録されます。複合型の検出では、型にエンティティ型を参照するプロパティがなく（つまり、すべてのプロパティがスカラー型である必要があります）、別の型のコレクションプロパティから参照されていないことも必要です。 。」私のアドレスクラスはこれらの基準を満たしています。文字列で構成されており、他の場所では使用されていません。

ただし、アプリでは（これが違いを生むかどうかはわかりませんが）、ユーザーを別の名前で呼んでいます。たとえば、Techsです。各技術者が独自のアドレスを持つことができるように、ユーザーのアドレス列をアドレスに分割したいと思います。上記の記事によると、EFはこれを推測し、複合型を自動的に処理する必要があります。ただし、コンテキストがTechを提供しようとすると、次の例外が発生します。

System.Data.EntityCommandExecutionException: An error occurred while executing t
he command definition. See the inner exception for details. ---> System.Data.Sql
Client.SqlException: Invalid column name 'Address_Street'.
Invalid column name 'Address_City'.
Invalid column name 'Address_State'.
Invalid column name 'Address_Zip'.

Tech.Addressプロパティを理解しようとしているように見えますが、各サブプロパティに間違った名前を付けています（たとえば、「City」ではなく「Address_City」）。

これを修正する方法について何かアイデアはありますか？

4

1 に答える 1

5

それは正しい振る舞いです。デフォルトの規則では、複合型にマップされたプロパティの前に常に型名が付きます。異なる列名を使用する場合は、データ注釈を使用してそれらをマップする必要があります。

public class Address
{
    [Column("City")]
    public string City { get; set; }
    ...
}

または流暢なAPIを介して：

modelBuilder.ComplexType<Address>().Property(a => a.City).HasColumnName("City");
于 2012-04-05T14:36:18.063 に答える