I wouldn't use generics here. I also wouldn't extend IPrincipal in the
way that you are.
First, if I did use generics, I would do something like this instead:
public interface IRolesAndRightsPrincipal :
System.Security.Principal.IPrincipal
{
bool IsInRole<T>(T role);
bool IsInAnyRole<T>(T[] roles);
bool IsInAllRoles<T>(T[] roles);
bool HasRight<T>(T right);
bool HasAnyRight<T>(T[] rights);
bool HasAllRights<T>(T[] rights);
}
The reason for this is that you might want to use strings or Guids on
any of the methods.
The constraint system fails you here, in that you can't say "allow this
or this". If you have the type parameter on the type level, you could at
least create a static constructor to perform a run-time check to see if the
type parameters are valid (it's not preferred, but it's the only way right
now). You don't have any such thing for method type parameters.
However, in this case, using strings seems to me to be nothing more than
a utility method to prevent the user from having to perform conversions to a
Guid. If this is the case, then this isn't something that you need to
provide a custom interface implementation for. You can just create a
utility wrapper which takes strings and performs the conversions, providing
overloaded methods which take string parameters. This would change your
interface to this:
public interface IRolesAndRightsPrincipal :
System.Security.Principal.IPrincipal
{
bool IsInRole(Guid role);
bool IsInAnyRole(Guid[] roles);
bool IsInAllRoles(Guid [] roles);
bool HasRight(Guid right);
bool HasAnyRight(Guid[] rights);
bool HasAllRights(Guid[] rights);
}
Your utility class would look like this:
public class RolesAndRightsPrincipalUtils : IRolesAndRightsPrincipal
{
// The implementation to defer to.
private IRolesAndRightsPrincipal implementation = null;
public RolesAndRightsPrincipalUtils(IRolesAndRightsPrincipal
implementation)
{
// Store the implementation.
this.implementation = implementation;
}
public bool IsInRole(Guid role)
{
// Forward the call.
return implementation.IsInRole(role);
}
public bool IsInRole(string role)
{
// Convert to a guid, and call the overload.
return implementation.IsInRole(new Guid(role));
}
// And so on...
}
This would keep your design clean, assuming everything was represented
with Guids (roles and rights).
Now, I am assuming that you are actually doing some work on the
combination of guids and rights to come up with a string which you are
passing to the IPrincipal implementation of IsInRole to determine if the
user has the appropriate rights. If this is the case, then you really don't
need the IRolesAndRightsPrincipal interface, as you can just have the logic
in the RolesAndRightsPrincipalUtils class, performing the transformation and
then calling IsInRole on the IPrincipal implementation.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard.caspershouse.com
}