http://blogs.msdn.com/b/ericlippert/archive/2009/02/02/properties-vs-attributes.aspx

 

Here is yet another question I got from a C# user recently:

I have a class that represents a business rule. I want to add some rule metadata that could be used by consumers to retrieve a friendlier rule name, description, and anything else that makes sense. Should this information be exposed as an attribute or property on the class?

I would say to absolutely go for a property in this case, for four reasons.

First, properties are highly discoverable. Consumers of this class can use IntelliSense to see that there is a property on the class called "Description" much more easily than they can see that there is an attribute.

Second, properties are much easier to use than attributes. You don't want to muck around with the code to extract strings from metadata attributes unless you really have to.

Third, data such as names and descriptions is highly likely to be localized in the future. Making it a property means that the property getter code can read the string out of a resource, a resource which you can hand off to your localization experts when it comes time to ship the Japanese version.

And fourth, let's go back to basic object-oriented design principles. You are attempting to model something -- in this case, the class is modeling a "business rule".

Note that a business rule is not a class. Nor is a rule an interface. A rule is neither a property nor a method. A rule isn't anyprogramming language construct. A rule is a rule; classes and structs and interfaces and whatnot are mechanisms that we use to implement model elements that represent the desired semantics in a manner that we as software developers findamenable to our tools.  But let's be careful to not confuse the thing being modeled with the mechanisms we use to model it.

Properties and fields and interfaces and classes and whatnot are part of the model; each one of those things should represent something in the model world. If a property of a "rule" is its "description" then there should be something in the model that you're implementing which represents this. We have invented properties specifically to model the "an x has the property y" relationship, so use them.

That's not at all what attributes are for. Think about a typical usage of attributes:

[Obsolete]

[Serializable]

public class Giraffe : Animal 

{ ...

Attributes typically do not have anything to do with the semantics of the thing being modeled. Attributes are facts about the mechanisms - the classes and fields and formal parameters and whatnot. Clearly this does not mean "a giraffe has anobsolete and a serializable." This also does not mean that giraffes are obsolete or serializable. That doesn't make any sense. This says that the class named Giraffe is obsolete and the class named Giraffe is serializable.

In short: use attributes to describe your mechanisms, use properties to model the domain.

总结:

使用attribute来描述机制，原理

使用property模拟领域