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

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

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

它的互操作性很差。例如，考虑这个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语言之间有良好的互操作。

这是一个有趣的方法。如果你约束右边的表达式为常数，那么你可以实现使用

Expression<Func<object, string>>

我认为这才是你真正想要的，而不是委托(你使用lambda来获得两边的名称) 参见下面的naive实现:

public static IDictionary<string, string> Hash(params Expression<Func<object, string>>[] hash) {
    Dictionary<string, string> values = new Dictionary<string,string>();
    foreach (var func in hash) {
        values[func.Parameters[0].Name] = ((ConstantExpression)func.Body).Value.ToString();
    }
    return values;
}

这甚至可以解决前面提到的跨语言互操作问题。

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

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

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

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

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

希望这能有所帮助

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

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

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

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