2010-02-03 30 views
0

je le modèle de base de données suivante:Modélisation d'une table de jointure

 
[User] 
Id 
Name 

[Role] 
Id 
Name 

[UserRole] 
UserId 
RoleId 
IsActive 

Et je veux créer une belle façon de représenter cette relation et la propriété qui est en elle avec des objets sans créer une classe pour représenter la table UserRole .

Des idées?

Merci beaucoup!

Répondre

0

Juste avoir un attribut d'un objet utilisateur appelé "rôles", qui contient une liste de rôles.

Vous pouvez également avoir 2 attributs, un pour une liste de rôles actifs un pour les inactifs, au cas où vous auriez besoin de gérer le drapeau actif en utilisant cet objet. Vous pouvez également avoir un attribut d'objet de rôle répertoriant les utilisateurs de ce rôle (au lieu ou en plus de l'attribut de rôle dans l'objet utilisateur), éventuellement avec une copie "inactive".

+0

Vous dites que ma classe Roles devrait être faite d'une référence de rôle et d'une propriété IsActive? – tucaz

+0

Non, il devrait avoir la propriété "users" et éventuellement une autre propriété "Incactive users". Dans votre table de données, isActive n'est pas une propriété du rôle individuel – DVK

+0

IsActive représente l'état de la relation entre un utilisateur et un rôle. Pour rendre l'exemple plus complet, disons qu'un utilisateur a plusieurs rôles et que certains d'entre eux peuvent être temporairement inactifs (IsActive = false). Vous direz que je devrais l'enlever s'il est inactif, mais c'est une exigence de l'entreprise pour être capable d'inactiver cette relation pendant un moment. Ou, je pourrais avoir d'autres propriétés dans la relation comme le nom de celui qui a autorisé cet utilisateur à avoir un rôle donc j'ajouterais AuthorizerUserId à la table UserRole. – tucaz

0

créer une vue qui rejoint UserRole et rôle:

[VUserRole] 
UserId 
RoleId 
RoleDescription 
IsActive 

et le modèle avec une classe UserRole. Ensuite, l'utilisateur a une collection de UserRole et IsActive est un attribut de UserRole.

Notez que cette solution ne fonctionnera pas bien avec la plupart des frameworks de persistance (any?) Et que la "bonne" façon de le faire est de mapper la table de jointure.

+0

Je cherche une solution plus OO sans créer la table N à N dans mon code. D'autres pensées? – tucaz

+0

La modélisation de la table de liens est la solution OO car il s'agit d'un nombre plusieurs-à-plusieurs avec des attributs supplémentaires. Ma solution ne crée pas la table de liens dans le code, elle utilise une classe qui combine UserRole et Role. Si vous êtes prêt à écrire tout le code d'accès aux données à la main, vous pouvez le modéliser comme vous le souhaitez. –

+0

En fait, je prévois de le mapper avec NHibernate. Des pensées supplémentaires? – tucaz