11

以下は、外部キー関係を定義しようとしている2つの部分的なテーブルです。

public class Form
{
    [Key, Column("FormID")]
    public System.Guid FormGUID { get; set; }

    [Column("PatGUID")]
    public Nullable<System.Guid> PatientGUID { get; set; }
}

public class Patient
{
    [Column("PatGUID")]
    public System.Guid PatientGUID { get; set; }

    [Key, Column("PatID")]
    public int PatientID { get; set; }

}

この例では、関連する情報、フィールド、ナビゲーションなどを除くすべてを削除しました。うまくいけば、あまり多くはありません。

PatGUIDフィールドを持つPatientテーブルへのFKを持つテーブルフォームがありますPatGUID。患者テーブルにはPatIDintKEYフィールドがあります。

コードファーストエンティティモデルのフィールドの名前を変更する必要があります。変更が必要なこの例の関連フィールドはPatGUIDに変更されていPatientGUIDます。

私が抱えている問題は、注釈または流暢さのいずれかを使用してこの外部キーを定義しようとすることです。

したがって、必要な最終結果は次のとおりです。

  • 主キーテーブル：患者、フィールド: PatGUID(PatientGUIDに名前が変更されました）

  • 外部キーテーブル：フォーム、フィールド: PatGUID(PatientGUIDに名前が変更されました）

これは大きな問題になるとは思われませPatient.PatGUIDんが、主キーではないこととPatGUIDフィールドの名前が変更されていることの組み合わせPatientGUIDにより、WCFデータサービスが適切な参照を使用して参照を適切に作成できず、適切な選択/結合ができませんでしたの：

SELECT … FROM  [dbo].[Form] AS [Extent1]
INNER JOIN [dbo].[Patient] AS [Extent2] ON [Extent1].[PatGUID] = [Extent2].[PatGUID]
4

1 に答える 1

16

EFは、プリンシパルのキーが主キーではなく、一意のキー制約を持つ他の列である関係をまだサポートしていません。これは機能要求リストに含まれていますが、実装されておらず、次のリリース（EF 6）のロードマップにも含まれていません。実装された場合（おそらくEF 7で）、本番環境の準備が整うまで1年以上待つことを期待してください。

特定のモデルでは、EFはとの間の関係をまったく認識しません。これFormは、がではなく、としてマークされてPatientいるためです。EFは、へのFKとしてではなく、通常のスカラープロパティとして扱われます。Patient.PatientID[Key]Patient.PatientGUIDForm.PatientGUIDPatient

理論的には、データベースからモデルを作成しない場合、またはコードファーストモデルからデータベースを作成しない場合、つまりモデル間でマップする場合、データベースの主キーではありませんが、モデルPatient.PatientGUIDのプロパティとして偽造することができます。[Key]および（既存の）データベースを手動で。しかし、これが他の場所で微妙な問題を引き起こさないかどうかはわかりません。

別の方法は、をフェッチして関連joinさせる場合は、LINQで手動ステートメントを作成することです。次に、キープロパティだけでなく、任意のプロパティを使用して2つのエンティティを結合できます。私の意見では、これはよりクリーンで「トリッキー」でないアプローチです。ただし、欠点は、との間にナビゲーションプロパティ（参照またはコレクション）がなく、積極的な読み込み（ ）、遅延読み込み、快適な「ドットパス構文」（など）などの機能を使用できないことです。 LINQクエリ。PatientsFormsPatientFormIncludeForm.Patient.SomePatientProperty

于 2013-03-12T22:01:56.710 に答える