オブジェクトをリレーショナル db 構造で表現する方法を誤解しています。
たとえば、次のような単純なテーブル構造があるとします。
それに基づいて Entity Framework モデルを生成すると、次のようになります。
ご覧のとおり、これは多対多の関連付けです。(どの料理にも多くの食材が含まれており、どの食材も多くの料理に使用できます)
では、ディッシュの材料の量など、追加のパラメーターが必要な場合はどうすればよいでしょうか? （もちろん、通常は、異なる料理の各材料ごとに異なる番号になります）.
追加の列をDish_FooIngridientテーブルに直接追加すると、自動モデル生成の機能が損なわれ、EF モデル デザイナーで関連付けを手動で修正し、後でいくつかの面倒なクエリを使用してオブジェクトを操作する必要があります。次のようなものに生成されるためです。
ご覧のとおり、必要のない冗長なプロパティが他にもあります。それを管理するためのより良い方法はありますか？複雑なプロパティや継承されたエンティティなどを使用している可能性がありますか?
Apress の「Entity Framework 4.0 Recipes」で示唆されているように、ペイロードなしで多対多の関係を設計することはあまり良い方法ではありません。
残念ながら、ペイロードのない複数の多対多の関係から始まったプロジェクトは、ペイロードが豊富な複数の多対多の関係で終わることがよくあります。モデルのリファクタリングは、特に開発サイクルの後半で、ペイロードを多対多の関係に対応させるために面倒な作業になる可能性があります。追加のエンティティが導入されるだけでなく、リレーションシップによるクエリとナビゲーション パターンも変更されます。一部の開発者は、すべての多対多の関係は何らかのペイロード (通常は合成キー) から開始する必要があると主張しているため、必然的に追加のペイロードを追加しても、プロジェクトへの影響は大幅に少なくなります。そこで、ベスト プラクティスをご紹介します。ペイロードのない多対多の関係があり、ペイロードを含めるように時間の経過とともに変化する可能性があると思われる場合は、リンク テーブルの余分な ID 列から始めます。テーブルをモデルにインポートすると、2 つの 1 対多の関係が得られます。つまり、記述したコードとモデルは、プロジェクトが成熟するにつれて追加される任意の数のペイロード列に対応できるようになります。追加の整数 ID 列のコストは、通常、モデルの柔軟性を維持するために支払うかなり小さな代償です。
理由がわかりません。フィールドを Dish_FoodIngredient に追加し、主キーを指定します。そのテーブルをモデルに追加すれば完了です。おそらくコードでいくつかのリファクタリングを行う必要がありますが、それを EF のせいにしないでください。
Model.edmx ファイルをダブルクリックし、オブジェクトの横の空白を右クリックして [データベースからモデルを更新...] をクリックし、[完了] をクリックすると、テーブルが更新されます。