我基于过去4或5年使用C＃属性的许多设计和框架。
但是最近我看到许多人开始不鼓励他们使用或改变他们的框架以减少他们的需要或使用。
我发现他们是天赐之物，但现在我开始怀疑自己错过了什么。
澄清： 使用约定优于配置正成为遵循ORM领域的主要原则。此区域是否可以使用配置文件（XML）映射字段，使用属性或具有直接映射到数据库表中字段的通用命名约定。我没有引用任何引用，但我已经阅读了一些反对意见，反对在混合中添加另一个属性。
但是我觉得我刚刚列出的三个选择属性仍然是最有意义的。 Config文件难以维护，常见的命名约定将您与数据库字段的实现联系起来。属性被准确放置在需要它们的位置，并且实现可以在不脱离使用位置的情况下进行更改。
答案 0 :(得分：7)
这是一个难以回答的问题。属性是另一种语言功能，如果使用正确但功能非常强大但确实存在滥用的可能性。我从未见过一个令人信服的理由完全抛弃属性的使用，并且没有理由认为它们是一个坏主意。
事实上恰恰相反。属性允许将特定于框架的信息添加到元数据中。通过类型层次结构无法轻易表达的信息。这大大增加了使用属性的框架的功能。
我当然看到一个或两个实施，人们滥用它们但没什么了不起的。你可以说得更详细点吗？是否有您正在讨论的特定属性/框架。
答案 1 :(得分：5)
这是一个非常广泛的问题，比如“我应该把奶酪放在我的砂锅里”;两者的答案是“这取决于你正在做什么”。
如果你大量使用addributes并使用它们几乎就像声明性编程范例一样，那么你可能会遇到麻烦。无论是来自某个反思的减速还是一般的可维护性都是任何人的猜测。
就像其他一切......在适当的时候使用它们，让你的代码更有效率或可读性。不要为了使用它们而使用它们，也不要为了放弃它们而放弃它们。
答案 2 :(得分：3)
属性实际上有两个用途：用户可见的东西，以及编译器发出的东西。
我假设你在谈论用户可见属性。
一般来说，我会说用户可见属性并不理想。
大多数时候，他们习惯在C＃之上嵌入某种形式的自定义语言。 DLINQ属性就是一个很好的例子。从消费者的角度来看，更好的方法是为宿主语言添加一流的支持。这最终会感觉更自然。 （使用语言支持定义表和外键将更容易使用所有疯狂的linq-to-sql属性）。
然而，实际上，扩展编程语言对于大多数开发人员而言成本过高。这些好处并不会影响成本。
也许有一天C＃将具有元编程功能，这将使这种事情变得容易。
但目前，该功能尚不存在。
这为您提供了3个选项：
通常＃1最终是最容易做出的选择，即使它不理想。
答案 3 :(得分：2)
在定义关于我的代码的元数据时，我发现它们非常有用。我使用它们来生成自定义报告，插件体系结构以及与第三方代码进行通信。
我想你可以按惯例做一切，但我喜欢他们。
答案 4 :(得分：1)
我在ASP.NET MVC中看到了大量使用Attributes。事实上，切换到MVC已经使我大大增加了对Attributes的使用。我不确定你对反属性反弹的看法来自何处，但我当然不会从MS看到它，至少在MVC方面是这样。
我特别喜欢Attributes可用于跨越那些装饰的控制器/动作提供横切行为（方面）的方式。看看如何构建MVC来处理动作调用之前和之后的属性调用，我必须相信这是让方面在MVC中工作的首选方法。
答案 5 :(得分：0)
好吧，如果ASP.NET MVC可以通过，我会说不用担心。使用反射和属性在该框架中完成了很多工作，我没有看到任何问题。 MVC是一个相当新的框架，它已经被广泛使用。从验证输入，处理错误到非常棒的ActionFilter属性，还有很多。所以不，我个人认为他们没有错。
答案 6 :(得分：0)
我个人认为属性与大多数语言功能一样，都有自己的位置，但可能会被滥用或滥用。
在正确的框架中，它们是非常宝贵的。它们肯定简化了诸如DI框架之类的东西（MEF是一个很好的例子），并且非常非常有用，例如测试框架。
但是，我认为疯狂添加用户定义的属性可能会过度。我个人喜欢使用属性，但尝试将其使用保持在最低限度，并且只在最有意义的地方使用它们。