2008-09-16 15 views
1

私はこの時点で思考以上になるかもしれないが、ここに行く質問があります...流暢なNHibernateのアーキテクチャの質問

私は2クラスのユーザーとグループがあります。ユーザーとグループは多かれ少なかれ多くの関係を持っています。私はIsAuthorizedプロパティを持っていたいと思っていました(いくつかのグループはプライベートなので、ユーザーは認証が必要です)。

ユーザテーブルとグループテーブルの両方のクラスを作成することをお勧めしますか?現在、私のクラスはこのように見えます。私はのためのクラスを記述する必要があり

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

:私のマッピングは両方のクラス(私は唯一のユーザーマッピングで1を示すんだけど、彼らは非常に似ている)で、以下のようなものです

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; } 

} 

このような表を結合しますか?

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

私は実際にグループメンバーシップの状態を調整できるようにしたいと私は、私はこのことについてに行くための最善の方法を考えるようにしようとしていると思います。

答えて

1

私は通常、実際のビジネスエンティティを表すクラスを作成するのが好きです。この場合、私は 'groupmembers'があなたのコードで価値のあるものを表すとは思わない。私にとって、ORMはデータベースをビジネスオブジェクトにマップする必要があります。つまり、クラスがデータベースレイアウトを正確に反映する必要はありません。

また、GroupMembersを実装することで、ユーザークラスとグループクラスの両方で厄介なコレクションになると思われます。 I.グループクラスにはユーザーリストとユーザーを参照するグループメンバーのリストがあり、その逆も同様です。私にとってこれはきれいではなく、テーブルの変更を維持して伝播することをより困難にします。

あなたが提案したようにデータベースに結合テーブルを残しておくことをお勧めします。また、ユーザーにwaitingtoacceptというグループのリストを追加してください。

これらの値は、waitingtoacceptフラグに基づいてデータベース内のジョイン・テーブルから引き出されます。

1

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

乾杯。