5

この EF のちょっとした癖のせいで、私は苛立たしい状況に陥っています。これは、動作の簡単なデモです。最初に DB スキーマ:

ここに画像の説明を入力

ご覧のとおり、これは product の特殊なケースであり、特別なコードを使用しRestrictedProductてサブクラスを作成するつもりです。Product

次に、EF データ モデルにインポートします。

ここに画像の説明を入力

おっとっと!EF は、には 2 つのフィールド (両方とも FK) しかないことを確認したため、とRestrictedProductの間の 1 対多の関係としてマップしました。データベースに戻って にフィールドを追加すると、EF モデルの見栄えが大幅に向上します。ProductRestrictionDummyRestrictedProduct

ここに画像の説明を入力

しかし、そのDummy分野はばかげていて無意味です。たぶん私はそれを削除できますか?DB テーブルとエンティティ モデルからフィールドを吹き飛ばし、DB からモデルを更新します...

ここに画像の説明を入力

大野!Product-Restriction協会は新しい名前 ( ) で戻ってきましたRestrictedProduct1! さらに、コンパイルされません:

エラー 3034: 行 (x, y) で始まるフラグメントのマッピングに問題があります: キーが異なる可能性のある 2 つのエンティティが同じ行にマッピングされています。これら 2 つのマッピング フラグメントが、AssociationSet の両端を対応する列にマップしていることを確認します。

DummyフィールドをRestrictedProductテーブルに保持する以外に、この動作を防ぐ方法はありますか?

4

2 に答える 2

2

同じ問題に遭遇しました。RestrictedProductテーブルにダミー フィールドを配置してエンティティの作成を強制する代わりに、RestrictedProduct.RestrictionIdフィールドを null 可能にすることもでき、EF はそのエンティティを生成します。次に、継承を使用するように変更できます。その後の「データベースからのモデルの更新」によって、望ましくないナビゲーション プロパティが発生することはありません。本当に良い解決策ではありませんが、回避策です。

于 2013-03-19T02:12:12.367 に答える
1

あなたの問題をゆっくりと見ていきましょう。

最初に決定する必要があるのは、制限された製品が本当に製品の特別なケースなのか、それとも各製品の拡張の可能性があるのか​​ということです。

元のDBスキームから、どの製品も単一の制限に関係しているように見えますが、単一の制限は多くの製品で共有できます..したがって、これは単純な1対多の状況であり、制限された製品は特別なケースではないことを意味します.製品!制限は、特定の方法で製品とは何の関係もない独立したエンティティです。

したがって、スキームの最初のインポートでは EF は正しいです。1. 製品には 0 または 1 の制限があります。2. 制限は、多くの製品に関連付けることができる別のエンティティです。

あなたの問題はわかりません。

于 2013-01-31T09:57:28.450 に答える