这不仅在一个层面上是可怕的。不，这一点也不像露比。这是对c#和。net的滥用。

关于如何以更直接的方式实现这一点，已经有许多建议:元组、匿名类型、流畅接口等等。

它之所以如此糟糕，是因为它只是为了自己的利益而幻想:

What happens when you need to call this from Visual Basic? .Attributes(Function(style) "width:100%") It's completely counter intuitive, and intellisense will provide little help figuring out how to pass stuff in. It's unnecessarily inefficient. Nobody will have any clue how to maintain it. What is the type of the argument going in to attributes? is it Func<object,string>? How is that intention revealing? What is your intellisense documentation going to say, "Please disregard all values of object"?

我认为你完全有理由感到厌恶。

我更喜欢

Attributes.Add(string name, string value);

它更加明确和标准，使用lambdas什么也得不到。

的确，它看起来像Ruby =)，至少对我来说，使用静态资源进行以后的动态“查找”不适合api设计的考虑，希望这个聪明的技巧是可选的api。

当你不需要添加键来设置值时，我们可以继承(或不继承)IDictionary并提供一个像php数组一样的索引器。它将是.net语义的有效使用，而不仅仅是c#，并且仍然需要文档。

希望这能有所帮助

这是表达式树的好处之一——可以检查代码本身以获得额外的信息。这就是如何将.Where(e => e. name == "Jamie")转换为等效的SQL Where子句。这是表达式树的一种巧妙使用，尽管我希望它不会超出这个范围。任何更复杂的代码都可能比它希望取代的代码更难，因此我怀疑它将是自我限制的。

我几乎没有遇到过这种用法。我认为这是“不合适的”:)

这不是一种常用的使用方式，它不符合一般的约定。当然，这种语法也有优点和缺点:

Cons

代码不是直观的(通常的约定是不同的) 它往往是脆弱的(重命名参数将破坏功能)。 测试起来有点困难(伪造API需要在测试中使用反射)。 如果大量使用表达式，它会变慢，因为需要分析参数而不仅仅是值(反射成本)。

Pros

在开发人员调整到这种语法之后，它的可读性更强。

底线——在公共API设计中，我会选择更明确的方式。

两个都是。这是对lambda表达式和语法的滥用。