这不仅在一个层面上是可怕的。不，这一点也不像露比。这是对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什么也得不到。

不，这当然不是常见的做法。这是违反直觉的，没有办法只看代码来弄清楚它是做什么的。你必须知道它是如何被使用的才能理解它是如何被使用的。

而不是使用委托数组提供属性，链接方法将更清晰，性能更好:

.Attribute("style", "width:100%;").Attribute("class", "test")

虽然输入起来有点费劲，但它清晰直观。

它的互操作性很差。例如，考虑这个c# - f#的例子

C#:

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F#:

Class1.Foo(fun yadda -> "hello")

结果:

打印“arg”(不是“yadda”)。

因此，库设计者应该避免这些“滥用”，或者至少提供一个“标准”的重载(例如，将字符串名作为一个额外的参数)，如果他们想在。net语言之间有良好的互操作。

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

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

希望这能有所帮助

恕我直言，这是一种很酷的方式。我们都喜欢将类命名为控制器将使其成为MVC中的控制器，对吧?所以在某些情况下，命名确实很重要。

这里的意图也很明确。很容易理解，.Attribute(book= > "something")将导致book="something"， .Attribute(log= > "something")将导致log="something"

我想如果你把它当作一种惯例来对待，那应该不成问题。我的观点是，只要能让你写更少的代码，让你的意图更明显，那就是一件好事。