1

この時点で考えすぎかもしれないという質問がありますが、ここに行きます...

ユーザーとグループの2つのクラスがあります。ユーザーとグループには多対多の関係があり、結合テーブル group_users に IsAuthorized プロパティが必要だと考えていました (一部のグループはプライベートであるため、ユーザーは承認が必要になるため)。

結合テーブルとユーザーおよびグループ テーブルのクラスを作成することをお勧めしますか? 現在、私のクラスは次のようになっています。

public class Groups
{
    public Groups()
    {
        members = new List<Person>();
    }
    ...
    public virtual IList<Person> members { get; set; }
}

public class User
{


    public User()
    {
       groups = new Groups()
    }
    ...
    public virtual IList<Groups> groups{ get; set; }

}

私のマッピングは、両方のクラスで次のようになっています (ユーザー マッピングの 1 つだけを表示していますが、非常に似ています)。

HasManyToMany<Groups>(x => x.Groups)
.WithTableName("GroupMembers")
.WithParentKeyColumn("UserID")
.WithChildKeyColumn("GroupID")
.Cascade.SaveUpdate();

このような結合テーブルのクラスを作成する必要がありますか?

public class GroupMembers
{
    public virtual string GroupID { get; set; }
    public virtual string PersonID { get; set; }
    public virtual bool WaitingForAccept { get; set; }
}

グループ メンバーシップのステータスを調整できるようにしたいのですが、これについて最善の方法を考えようとしていると思います。

4

2 に答える 2

1

はい、UserGroupBridgeのような別のクラスが必要です。もう1つの優れた副作用は、潜在的に重いユーザー/グループオブジェクトをNHibernateセッションにロードせずに、ユーザーメンバーシップとグループメンバーを変更できることです。

乾杯。

于 2008-09-16T02:53:08.653 に答える
1

私は通常、実際の事業体を表すクラスを作成することだけが好きです。この場合、「groupmembers」はコード内で価値のあるものを表すとは思いません。私にとって、ORMはデータベースをビジネスオブジェクトにマップする必要があります。これは、クラスがデータベースレイアウトを正確にミラーリングする必要がないことを意味します。

また、GroupMembersを実装することで、ユーザークラスとグループクラスの両方に厄介なコレクションが作成されることになると思います。IEのグループクラスには、ユーザーのリストと、ユーザーを参照するグループメンバーのリストがあり、ユーザークラスの場合はその逆になります。私にとって、これはそれほどクリーンではなく、変更を維持してテーブルに伝達するのが難しくなります。

提案したとおりに結合テーブルをデータベースに保持し、waitingtoacceptというグループのリストをユーザーに追加し、（意味がある場合は）waitingtoacceptというユーザーのリストをグループに追加することをお勧めします。

次に、waitingtoacceptフラグに基づいて、データベース内の結合テーブルから値を取得します。

于 2008-09-16T03:04:44.400 に答える