史蒂文 :: Release 2.0

I've rarely using the Attributes class in .Net mainly because often when i consider it's use, i can see better ways of doing it in a more dynamic way.

As an example of this in the real world, not too long ago i was discussing Windows Authorization Manager in conjunction with Web Services. In fact, what the client wanted to do, was to protect a specific method call but push control out to application administrators. Of course, .Net offers Role based security as a technique of protecting methods based on the Windows groups a user belongs to. This uses attributes and can be written something like:

[SecurityRole("Manager")]
public int Add( int operand1, int operand2 )
{
return operand1 + operand2;
}

This limits the Add() method to being called by users who are members of the Manager role which is an issue if you wish to make access to this method more dynamic and perhaps add other roles at some point in the future. Using AzMan, you can check at runtime whether the context user has access to the method using an out-of-band role management database, maintained by application administrators.

public int Add( int operand1, int operand2 )
{
(!store.HasAccess(currentIdentity, "Add")) {
throw new SecurityException("Access Denied");

return operand1 + operand2;
}

In situations where you want to interop on platforms or make calls accross boundaries such as a business component and stored procedure which may not be using SSPI, the having your role information accessible out-of-band can be hugely beneficial!

Furthermore, in most cases where I pull data for configuration purposes, i figure there is a good reason why they are configurable in the first place and so make these changeable through the web or application configuration file. Even a simple switch to move to debug mode or limit the size of soap messages can be useful in an external configuration file than as an attribute in compiled code. I suspect the huge effort that went into declarative support in WCF has this at the forefront of the original design.

I struggle to think of many places where attributes derived from the Attribute class and applied imperatively in code are useful. Perhaps "WrittenBy" or "CheckedBy" which are immutable on a per version basis, but as far as i'm concerned, anything that has more than one potential configurable value, just now or in the future, should be available declaratively.