4

「ユーザー」テーブルから「レポート」テーブルまで、いくつかのナビゲーションプロパティがあります。生成されるナビゲーションプロパティには、明らかに次のようにアクセスします。

USER.REPORTs.Where(x => ...)
USER.REPORTs2.Where(x => ...)
USER.REPORTs3.Where(x => ...)

1つ目はユーザーcreatedId、2つ目はUserApprovedIdなどです...基本的なものです。

これらを解釈するのは非常に困難です。EDMXにアクセスしてナビゲーションプロパティを確認しないと、ナビゲートしているプロパティを特定するのは困難です。

これで、独自のEnd1 / End2ナビゲーションプロパティをプロパティマネージャーで作成できることがわかりましたが、モデルを再作成するとこれらは失われます。

これを回避する方法はありますか？

4

5 に答える 5

5

私はこれを試していませんが、ここにアイデアがあります。すべてのエンティティタイプは部分的なクラスなので、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;}
    }
}

.edmxコード全体で上記のプロパティを使用します。VisualStudioがファイルを生成するときに同じロジックが使用されるため、ラップされたプロパティは変更されません。ラップされたプロパティの名前が変更された場合でも、コードを1か所で調整する必要があります。

于 2012-05-14T09:32:23.893 に答える
1

問題を正しく理解しているかどうかはわかりませんが、USERオブジェクトから直接REPORTs.Where（...）LINQクエリの結果にアクセスするための「よりクリーンな」方法が必要なようです。その場合は、次のようにUSERオブジェクトの拡張機能を作成することをお勧めします。

public static class UserExtensions
{
 public static List<REPORT> ReportsWithSomeCondition(this USER user)
 {
    return user.REPORTs.Where(...).ToList();
 }
}

そして、これをきれいに呼び出すことができる方法は次のとおりです。

List<REPORT> results = USER.ReportsWithSomeCondition()

完全に要点を逃した場合は、質問を明確にしてください。この回答を削除します。

于 2012-05-09T17:13:26.123 に答える
1

私はあなたの質問から理解するのと同じ問題を抱えていると思います。

ナビゲーションプロパティの名前をできるだけ明確に保ちたいが、edmxからモデルを再作成するときはいつでも？！。

実際、もっと良い解決策があるかどうかを願っていますが、ここで私がしていること：

  1. データベース内のリレーションに：FK_Users_CreateUserReport、FK_Users_ApprovedUserReport...などの適切な名前を付けるか、ナビゲーションプロパティの名前を次のように変更ApprovedUserReportしCreateUserReportます。

  2. モデルを再作成するたびに実行するヘルパーコードを作成すると、このコードによって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());
}

最後に、コードのみのパターンを使用した場合、この問題は解消されますが、その場合は、モデルをデータベースと手動で一致させる必要があります。

于 2012-05-10T09:02:44.687 に答える
0

部分クラスメカニズムを使用して、すべてのカスタムエンティティコードを個別のコードファイルに配置する必要があります。これにより、カスタムコードに影響を与えることなく、生成されたコードを生成できます。

于 2012-05-15T09:34:05.313 に答える
0

ワヒドの答えは、長期的なメンテナンスに最適なようです。拡張機能の「バディクラス」として使用するパーシャルクラスにインターフェイスプロパティを実装し、メタデータリンクを設定することを検討しました。ただし、インターフェイスしているT4テンプレートのプロパティは引き続きパブリックであり、プライベートである必要があります。

ワヒドの提案を改善するため。外部キー関係の命名方法の基準を変更する代わりに、それらを拡張することを選択しました。

FK_Users_Report_CreateUserReportが実際に私たちのソリューションになります。最初の2つの値の標準の命名規則が維持され、モデルコードの更新では、3番目の下線と3番目の値が付いているもののナビゲーションプロパティ名のみを変更するように強制できます。DB内の外部キーの標準の命名規則に従わなかった場合、他のナビゲーションプロパティ名に影響を与えないようにします。

于 2013-12-20T17:24:17.110 に答える