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