2008-09-16 10 views
1

Ich habe eine Frage, die ich vielleicht über denke, aber hier geht ...Fließende NHibernate Architecture Frage

Ich habe 2 Klassen Benutzer und Gruppen. Benutzer und Gruppen haben eine Viele-zu-Viele-Beziehung und ich dachte, dass die Join-Tabelle group_users eine IsAuthorized-Eigenschaft haben wollte (da einige Gruppen privat sind - Benutzer benötigen eine Autorisierung).

Würden Sie empfehlen, eine Klasse für die Join-Tabelle sowie die Tabelle für Benutzer und Gruppen zu erstellen? Derzeit sehen meine Klassen so aus.

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

} 

Meine Zuordnung ist wie folgt in beiden Klassen (ich nur die eine in der Benutzer-Mapping zeigt aber sie sind sehr ähnlich):

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

Soll ich schreiben eine Klasse für die Join Tabelle, die so aussieht?

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

Ich würde wirklich in der Lage sein wie die Gruppenmitgliedschaft Status einzustellen, und ich denke, ich versuche, die beste Art und Weise zu denken, um dies zu realisieren.

Antwort

1

Ich mag generell nur Klassen erstellen, die tatsächliche Geschäftseinheiten darstellen. In diesem Fall glaube ich nicht, dass Gruppenmitglieder etwas Wertvolles in Ihrem Code darstellen. Für mich sollte das ORM die Datenbank auf Ihre Geschäftsobjekte abbilden. Dies bedeutet, dass Ihre Klassen das Datenbanklayout nicht genau spiegeln müssen.

Auch ich vermute, dass Sie durch die Implementierung von GroupMembers einige böse Sammlungen in Ihren Benutzer- und Gruppenklassen enden. I.E. Die Gruppenklasse enthält die Liste der Benutzer sowie eine Liste der Gruppenmitglieder, die auf einen Benutzer verweisen, und umgekehrt für die Benutzerklasse. Für mich ist das nicht so sauber und es wird es schwerer machen, Änderungen an den Tischen beizubehalten und zu verbreiten.

Ich würde empfehlen, die Join-Tabelle in der Datenbank zu belassen, wie Sie vorgeschlagen haben, und fügen Sie eine Liste der Gruppen hinzu, die in den Benutzern als wartend akzeptiert werden und (wenn es auch Sinn macht) Liste der Benutzer hinzufügen, die in Gruppen angerufen werden.

Diese würden dann ihre Werte aus Ihrer Join-Tabelle in der Datenbank basierend auf dem Wartestapel-Flag ziehen.

1

Ja, sicher, Sie brauchen eine andere Klasse wie UserGroupBridge. Ein weiterer guter Nebeneffekt ist, dass Sie Benutzermitgliedschaften und Gruppenmitglieder ändern können, ohne möglicherweise schwere Benutzer-/Gruppenobjekte in die NHibernate-Sitzung zu laden.

Prost.