私は 'Users'テーブルから 'Reports'テーブルにいくつかのナビゲーションプロパティを持っています。生成されたナビゲーションプロパティは明らかに、このようにアクセスされていますモデルの再構築後にカスタムナビゲーションプロパティを保持するにはどうすればよいですか？
USER.REPORTs.Where(x => ...)
USER.REPORTs2.Where(x => ...)
USER.REPORTs3.Where(x => ...)
最初のものは、ユーザーcreatedId、二UserApprovedIdなど...基本的なものです。
これらは、解釈するのが非常に難しいです。 EDMXにアクセスせずにナビゲーションプロパティをチェックすることなく、どのプロパティをナビゲートしているのかがわかりにくい。
これで、プロパティマネージャで自分のEnd1/End2ナビゲーションプロパティを作成できますが、モデルを再作成するとこれらは失われます。
方法はありますか？
私はこれを試していませんが、ここでアイデアがあります：すべてのエンティティタイプが部分的なクラスなので、Visual Studioで生成されたナビゲーションプロパティを便利な名前の別のプロパティにラップするのはなぜですか？あなたはその後、ナビゲーションプロパティをラップするには、別のファイルを作成することができます
public partial class MyEntity : EntityObject
{
#region Navigation Properties
public EntityCollection<MyOtherEntity> Other_Entities1
{
// ...
}
#endregion
}
：あなたはこのようなものがあるでしょう、あなたのデザイナーのファイルで
public partial class MyEntity
{
public EntityCollection<MyOtherEntity> OtherEntities
{
get { return Other_Entities1;}
}
}
あなたはプロパティを使用しますVisual Studioが.edmxファイルを生成するときに同じロジックが使用されるため、ラップされたプロパティは変更されません。 ラップされたプロパティの名前が変更されても、コードを1か所で調整する必要があります。
最初はうまくいくようですが、折り返しプロパティはLinq to Entitiesでは使用できません... – Rodolphe
あなたの問題を正しく理解しているかどうかはわかりませんが、REPORTs.Where（...）の結果に直接アクセスするための「クリーンな」方法が必要なように聞こえますオブジェクト。その場合は、私はこのようなユーザオブジェクトの作成拡張を提案する：
public static class UserExtensions
{
public static List<REPORT> ReportsWithSomeCondition(this USER user)
{
return user.REPORTs.Where(...).ToList();
}
}
そして、あなたはきれいにこれを呼び出すことができる方法がある：
List<REPORT> results = USER.ReportsWithSomeCondition()
私は完全にポイントを逃した場合は、明確にしてくださいあなたの質問と私はこの答えを削除します。
私はあなたの質問から私が理解するのと同じ問題があると思います。
ナビゲーションプロパティの名前は可能な限り明確にしたいが、いつでもモデルをedmxから再作成する必要があります。よりよい解決策が、ここで私がやっている何があるかどう
は、実際に私は願っています：私たちは「FK_Users_CreateUserReport、FK_Users_ApprovedUserReport ...または任意の適切な名：データベースに
ApprovedUserReportとCreateUserReportのようにナビゲーションプロパティの名前を変更します。モデルを再作成するときに実行するヘルパーコードを作成します。このコードはedmxファイルを開き、次のようなすべてのナビゲーションプロパティを更新します。 ：
// file here is the path to your edmx file
if (!string.IsNullOrEmpty(file))
{
var ns = XNamespace.Get("http://schemas.microsoft.com/ado/2008/09/edm");
var doc = XDocument.Load(file);
var list = (from xElem in doc.Descendants(ns + "NavigationProperty")
where xElem.Attribute("Name").Value.StartsWith("REPORTs"))
select xElem).ToList();
foreach (var item in list)
{
var newName = item.Attribute("Relationship").Value.Split('_').LastOrDefault();
if (!newName.Contains("."))
item.SetAttributeValue("Name", newName);
else
{
var ss = newName.Split('.').LastOrDefault();
}
}
doc.Save(file);
MessageBox.Show(list.Count.ToString());
}
あなたはコードのみのパターンを使用した場合に最終的な事は、この問題がなくなっていますが、その場合には、あなたの手によって、データベースと一致して、あなたのモデルを維持する必要があります。
部分クラスメカニズムを使用して、すべてのカスタムエンティティコードを別々のコードファイルに配置する必要があります。これにより、生成されたコードがカスタムコードなしで生成されます。
ワヒドの答えは、長期的なメンテナンスに最適なようです。私たちは、私たちが拡張のための「バディクラス」として使用するパーシャルクラスでインターフェイスプロパティを実装し、メタデータリンクを設定することを検討しました。しかし、T4テンプレートのプロパティはまだ公開されており、プライベートでなければなりません。
ワヒドの提案を改善する。私たちは、外部キーの関係をどのように名付けるかの基準を変更し、それらを拡張することにしました。
FK_Users_Report_CreateUserReportが実際に私たちのソリューションになります。最初の2つの値の標準命名規則が維持され、更新モデルコードでは、3番目のアンダースコアと3番目の値のナビゲーションプロパティ名のみを変更するように強制できます。 DB内の外部キーの標準命名規則に従わなかった場合、他のナビゲーションプロパティ名に影響を与えないようにします。
問題をはっきりと理解するために情報を追加してください。うまくいけば、私はここにいくつかの助けを加えることができますか？ – AvkashChauhan
MVCとは関係ありませんが、絶対にEFの問題です。 –
どのようにモデルを作り直していますか？データベースからのみ更新する場合、名前は変更されません。ナビゲーションプロパティの名前を自由に変更し、その名前でコードにアクセスできます。 – MiBu