2008-09-16 9 views
1

J'ai une question que je suis peut-être en train de penser à ce point mais ici va ...Fluent NHibernate Architecture Question

J'ai 2 classes Utilisateurs et Groupes. Les utilisateurs et les groupes ont une relation plusieurs à plusieurs et je pensais que la table de jointure group_users que je voulais avoir une propriété IsAuthorized (parce que certains groupes sont privés - les utilisateurs auront besoin d'autorisation).

Recommanderiez-vous la création d'une classe pour la table de jointure ainsi que la table User and Groups? Actuellement, mes cours ressemblent à ceci.

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

} 

Ma cartographie est comme suit dans les deux classes (je ne participe qu'à celui de la mise en correspondance des utilisateurs, mais ils sont très similaires):

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

devrais-je écrire une classe pour la joindre une table qui ressemble à ceci?

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

Je voudrais vraiment pouvoir régler le statut des membres du groupe et je pense que je suis en train de penser à la meilleure façon d'aller à ce sujet.

Répondre

1

En général, j'aime créer des classes qui représentent des entités commerciales réelles. Dans ce cas, je ne pense pas que les «membres du groupe» représentent quelque chose de valeur dans votre code. Pour moi, l'ORM doit mapper la base de données à vos objets métier. Cela signifie que vos classes ne doivent pas refléter exactement la disposition de la base de données.

Aussi je soupçonne qu'en mettant en place GroupMembers, vous finirez avec quelques collections désagréables dans vos classes d'utilisateur et de groupe. C'EST À DIRE. la classe de groupe aura la liste des utilisateurs et aussi une liste des membres du groupe qui référence un utilisateur et vice versa pour la classe d'utilisateurs. Pour moi, ce n'est pas si propre et il sera plus difficile de maintenir et de propager les modifications apportées aux tables. Je suggère de garder la table de jointure dans la base de données comme vous l'avez suggéré, et ajouter une liste de groupes appelée waitingtoaccept dans les utilisateurs et (si cela a aussi du sens) ajouter Liste d'utilisateurs appelée waitingtoaccept dans les groupes.

Ils tireraient ensuite leurs valeurs de votre table de jointure dans la base de données en fonction de l'indicateur waitingtoaccept.

1

Oui, bien sûr, vous avez besoin d'une autre classe comme UserGroupBridge. Un autre bon effet secondaire est que vous pouvez modifier l'appartenance de l'utilisateur et les membres du groupe sans charger d'objets User/Group potentiellement lourds dans la session NHibernate.

Cheers.