Tout d'abord, veuillez noter que faire quelque chose comme entity.underlyingEntity.underlyingEntity.method()
est considéré comme une odeur de code selon la loi de Demeter . De cette façon, vous exposez de nombreux détails d'implémentation au consommateur. Et chaque besoin d'extension ou de modification d'un tel système sera très douloureux.
Donc, étant donné cela, je vous recommanderais d'avoir une méthode HasRole
ou IsAdmin
sur le User
commentaire de CodesInChaos. De cette façon, la façon dont les rôles sont implémentés sur l'utilisateur reste le détail de l'implémentation pour le consommateur. Et il semble également plus naturel de demander à l'utilisateur quel est son rôle au lieu de lui demander des détails sur son rôle, puis de décider en fonction de cela.
Veuillez également éviter d'utiliser string
s sauf si nécessaire. name
est un bon exemple de string
variable car le contenu est inconnu au préalable. D'un autre côté, quelque chose comme role
lorsque vous avez deux valeurs distinctes bien connues au moment de la compilation, vous feriez mieux d'utiliser un typage fort. C'est là que le type d'énumération entre en jeu ...
Comparer
public bool HasRole(string role)
avec
public enum Role { Admin, User }
public bool HasRole(Role role)
Le deuxième cas me donne beaucoup plus d'idée de ce que je devrais faire circuler. Cela m'empêche également de transmettre par erreur un invalide string
au cas où je n'aurais aucune idée de vos constantes de rôle.
Vient ensuite la décision sur l'apparence du rôle. Vous pouvez soit utiliser enum directement stocké sur l'utilisateur:
public enum Role
{
Admin,
User
}
public class User
{
private Role _role;
public bool HasRole(Role role)
{
return _role == role;
}
// or
public bool IsAdmin()
{
return _role == Role.Admin;
}
}
D'un autre côté, si vous voulez que votre rôle ait lui-même un comportement, il devrait définitivement cacher à nouveau les détails de la façon dont son type est décidé:
public enum RoleType
{
User,
Admin
}
public class Role
{
private RoleType _roleType;
public bool IsAdmin()
{
return _roleType == RoleType.Admin;
}
public bool IsUser()
{
return _roleType == RoleType.User;
}
// more role-specific logic...
}
public class User
{
private Role _role;
public bool IsAdmin()
{
return _role.IsAdmin();
}
public bool IsUser()
{
return _role.IsUser();
}
}
Ceci est cependant assez verbeux et la complexité augmenterait avec chaque ajout de rôle - c'est généralement ainsi que le code se termine lorsque vous essayez d'adhérer pleinement à la loi de Demeter. Vous devez améliorer la conception en fonction des exigences concrètes du système modélisé.
Selon votre question, je suppose que vous feriez mieux de choisir la première option avec enum directement User
. Si vous avez besoin de plus de logique sur le Role
, la deuxième option doit être considérée comme un point de départ.
User.HasRole(Role.Admin)
.