经常有人提出这样的问题：
一个表示业务规则的类，我想在这个类上加一些表示规则的元数据，可以让用户获取更友好的规则名，描述，和其他一些信息。我该采用特性还是属性呢？
我的建议是使用属性。有4个原因：
首先，属性一眼就能看出。类的使用者可以使用智能感知来看到类的属性，比使用特性方便直观很多。
第二，属性使用比特性方便很多。你不希望搞一堆代码，从元数据特性中抽取string。除非你必须这样做。
第三，数据比如名称和描述是很有可能是要本地化的。设为属性意味着属性你可以从外部的源中获得属性值，比如你想本地化为日文版本。
最后。让我们看一下基本的面向对象设计原则，我们总是试图将事物模型化，着这个例子中，就是模型化一个“业务规则”
注意，一个业务规则不是一个类，规则也不是一个接口。一个规则既不是属性也不是方法，一个规则并不是任何程序语言结构，规则就是规则，类和结构，接口这些东西是我们用来实现模型的一种机制，这种模型使用了我们认为合适的语法。小心不要混淆了需要模型化的事物和如何模型化的机制。
属性和字段，接口和类等这些东西是模型的一部分，每一个都表示了模型世界中的某个事物。我们发明了属性，用来模型化事物X具有Y属性这种关系。
特性不是这样的。看下面的一个特性的典型用法：
[Obsolete]
[Serializable]
public class Giraffe : Animal
{ ...
特性对于模型化一个事物没有任何作用。特性是面向机制——类和字段，参数之类。很明显，上例中。并不是说长颈鹿有一个过时的和可序列化的。也不表示长颈鹿是过时的或者可序列化的。这只是说这个Giraffe这个类是过时的，Giraffe这个类是可以序列化的。
总之，使用特性描述你的机制，使用属性模型化你的事物。
http://blogs.msdn.com/b/ericlippert/archive/2009/02/02/properties-vs-attributes.aspx
本文转自cnn23711151CTO博客，原文链接：http://blog.51cto.com/cnn237111/917669 ，如需转载请自行联系原作者
