0

「グループ タイプ」の GUID と「参照オブジェクト」の GUID を持つ一般的なグループ メンバーテーブルがあります。例として、顧客のテーブル (それぞれに GUID がある) がある場合、グループ GUID を作成することで「支払い済み」の下にグループ化し、それぞれの GUID ですべての顧客を参照する「グループ メンバー テーブル」でそれらをグループ化できます。これにより、展開する際に (余分なテーブルを追加することなく)、任意のタイプのグループをモデルに追加できます。

これが問題です。特定のグループのユニバーサルグループ メンバーテーブルをフィルター処理するために、エンティティにサブクエリを作成しました。そのようです：

  partial void ElementsNotMemberOfGroup_PreprocessQuery(int? UniversalGroupTypeIDParameter, int? UniversalGroupsIDParameter, ref IQueryable<UniversalGroupMember> query)
    {
        query = query.Where(x => x.UniversalGroup.UniversalGroupType.UniversalGroupTypeID == UniversalGroupTypeIDParameter);
        query = query.Where(x => x.UniversalGroup.UniversalGroupsID != UniversalGroupsIDParameter);
    }

これは、グループ内の参照されたオブジェクトの GUID を返しますが、ユーザーの場合は役に立ちません。顧客情報を抽出して表示できるように、実行時にこのテーブルと顧客テーブルを GUID で結合する必要があります。

何か案は？

4

1 に答える 1

0

LightSwitch は、こ​​の種のシナリオを念頭に置いて作成されたわけではありません。LightSwitch を使用すると、"関連" しているテーブル間のリレーションシップを簡単に作成できます。これを行うと、エンティティ間の手動結合は必要ありません。

あなたが説明していることと同様のことを行うことは可能ですが (以下のリンクを参照)、それを達成するにはより多くの作業が必要であり、私の意見では、余分な手間をかける価値はありません。それだけでなく、お気づきのように、最も単純な操作でさえ複雑になります。

本質的には、LightSwitch を使用するのではなく、LightSwitch に対して作業を行っているのです。この種の手動最適化を本当に行う必要がある場合、LightSwitch は最適な製品ではない可能性があります。

Beth Massi のブログ記事Using Different Edit Screens Based on Record Types (Table Inheritance)は、まさにあなたが行っていることではありませんが、プロジェクトで LightSwitch を引き続き使用することにした場合は、いくつかのアイデアが得られるかもしれません。

于 2013-08-30T02:51:07.317 に答える