关于抽象lambda表达式的建议

Question

我发现自己在C＃应用程序中越来越多地使用lambda表达式。最常见的情况是使用Expression＆lt; Func＆lt; Object＆gt;＆gt;消除对属性名称的魔术字符串引用。例如，我可以有一个方法，如：

public void SomeFunction(Expression<Func<Object>> expression)
{ ... }

我可以将方法称为：

SomeFunction(() => SomeProperty);

到目前为止，处理表达式的方法内部的逻辑几乎完全相同，这让我考虑了将其提取为可重用组件的方法。有没有人这样做过？我应该注意哪些潜在的陷阱？

Answer 1

嗯，是的，不是。最大的区别在于用于填充字典的推断。 （我同意对该帖子的大多数回复，并且不喜欢它在这种情况下的使用。）这里，我只是使用表达式传递对属性的引用而不是传入包含属性的魔术字符串名。

而且，我的初始实现实际上直接来自Microsoft博客！在那种情况下，我正在使用它的一个实例是在我的RaisePropertyChanged方法中。使用表达式，我可以调用：

RaisePropertyChanged(() => MyProperty);

而不是：

RaisePropertyChanged("MyProperty").

恕我直言，这使代码更加可靠和可维护，因为我在编译时进行了类型检查/验证，所以我会立即知道是否有人更改了名称或从调用对象中删除了属性。

我的问题是我在其他几个地方也使用相同的方法，并发现我正在复制用于处理表达式的逻辑。我考虑创建一个派生自Expression＆lt; Func＆lt; Object＆gt;＆gt;的新类。并且每当我想要这种行为时都使用它作为类型，但我知道有很多表达式，lambda等等，所以我想有信心我不会打开Pandora的Box这样做。