您认为C属性(或类似的机制)是一个好主意还是不鼓励使用它们?

属性实际上有两个用途:作为用户可见的东西,和作为编译器发出的东西。

我假设您在谈论用户可见属性。

一般来说,我认为用户可见属性并不理想。

大多数时候,它们被用来在C之上嵌入某种形式的自定义语言。dlinq属性就是一个很好的例子。从消费者的角度来看,更好的方法是向宿主语言添加一流的支持。最后会感觉更自然。(拥有定义表和外键的语言支持比使用所有疯狂的linq-to-sql属性要容易得多)。

然而,在现实中,对大多数开发人员来说,扩展编程语言太过昂贵。好处并不能抵消成本。

也许有一天,C会有元编程功能,这将使做这种事情变得容易。

然而,目前这种能力并不存在。

这将为您提供3个选项:

1. 使用属性
2. 使用动态语言,并在运行时生成代码
3. 只是不要使用生成程序

通常1是最容易做出的选择,即使它不理想。

这是一个很难给出一般答案的问题。属性是另一种语言特性,当正确使用时非常强大,但确实有可能被滥用。我从来没有看到过一个令人信服的理由完全放弃属性的使用,真的没有理由认为它们是一个坏主意。

事实上恰恰相反。属性允许将框架特定的信息添加到元数据中。不能简单地通过类型层次结构表示的信息。这显著提高了使用属性的框架的能力。

我当然看到过一两个实现,其中人们有点滥用它们,但没有什么了不起的。你能更具体一点吗?你说的是特定的属性/框架吗?

这是一个相当广泛的问题,比如“我应该把奶酪放进我的砂锅里吗”;答案是“这取决于你在做什么”。

如果您大量使用了addribute,并且几乎像使用声明性编程范式一样使用它们,那么在使用过程中可能会遇到麻烦。无论是来自于反射的某个地方的减速,还是仅仅是一般的可维护性,这都是任何人的猜测。

它和其他所有东西一样……在适当的时候使用它们,使代码更有效或更可读。不要为了使用它们而使用它们,也不要为了抛弃它们而抛弃它们。

当涉及到定义关于代码的元数据时,我发现它们非常有用。我使用它们来生成定制报告、插件架构以及与第三方代码通信。

我想你可以按惯例做事,但我喜欢。

我看到ASP.NET MVC中大量使用了属性。事实上,切换到MVC使我显著地增加了属性的使用。我不确定你对反属性反弹的看法来自何处,但我肯定没有从微软看到,至少在MVC方面。

我特别喜欢使用属性来跨这些控制器/动作提供横切行为(方面)的方式。了解如何构建MVC来处理动作调用前后的属性调用,我必须相信这是让方面在MVC中工作的首选方法。

好吧,如果ASP.NET MVC有什么值得一提的,我会说不要担心。在这个框架中,使用反射和属性做了很多工作,所以我看不到它有任何问题。MVC是一个全新的框架,它被广泛使用。从验证输入、处理错误到非常棒的actionfilter属性,有很多。所以不,我个人认为他们没有什么问题。

我个人认为属性,像大多数语言特征一样,有它们的位置,但可能被滥用或误用。

在正确的框架中,它们是无价的。它们确实简化了DI框架之类的事情( MEF 是一个很好的例子),对于测试框架之类的东西非常非常有用。

不过,我认为疯狂地添加用户定义的属性可能会有点过分。我个人喜欢使用属性,但是尽量减少它们的使用,并且只在它们最有意义的地方使用它们。