从 getter/setter 的 MethodInfo 中查找托管 PropertyInfo
我使用反射在运行时进行一些类型分析。 如果我有一个 MethodInfo 实例, 我如何判断这是一个“真正的”方法还是属性的 getter/setter 方法? 如果它是一个属性,我如何找到它的托管 PropertyInfo?
I do some type analysis in runtime using Reflection. If I have a MethodInfo instance,
how can I figure out if this is a "real" method or is a getter/setter method of a property? And if it is a property, how can I find the its hosting PropertyInfo back?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
好吧,getter 和 setter 背后的方法是“真正的”方法。
重新跟踪回属性 - 模式(return 与 take 1 arg)将有助于缩小范围 - 但您必须对每个属性调用 GetGetMethod/GetSetMethod 才能找到该属性。
您可以可能尝试
名称
(少get__/set__) - 但这感觉很脆弱。 这是更长的版本(不使用Name
):Well, the method behind a getter and setter are "real" methods.
Re tracking back to a property - the pattern (return vs take 1 arg) will help narrow it - but you'll have to call GetGetMethod/GetSetMethod on each to find the property.
You could probably try the
Name
(less get__/set__) - but that feels brittle. Here's the longer version (no use ofName
):Ecma 335 指定(但不要求)编译器使用 get_/set_ 前缀(第 22.28 章)。 我不知道有什么语言可以违背这一建议。 让它变得简单:
Ecma 335 specifies (but does not demand) that compilers use the get_/set_ prefixes (chapter 22.28). I don't know any language that breaks that recommendation. Making it easy:
查看
MethodBase.IsSpecialName
< /a>. 不应该明显可见的方法(例如属性访问器、事件订阅方法和运算符重载)使用此标志。据我所知,如果不迭代属性并比较方法,就无法找到
PropertyInfo
。Look into
MethodBase.IsSpecialName
. Methods which shouldn't be plainly visible, such as property accessors, event subscription methods and operator overloads use this flag.To my knowledge, there isn't a way to find the
PropertyInfo
without iterating through the properties and comparing the methods.我真的很想将此作为评论,但我不能,因为我的代表不够高:(
Marc Gravell 的代码中有一个错误:如果它是一个索引器,它将返回 null,即使父属性存在。它很好有这种快速失败的情况,但我认为我们只能在它既没有返回值也没有参数的情况下这样做:
I'd really like to leave this as a comment, but I cant since my rep isnt high enough :(
Theres a bug in Marc Gravell's code: if its an indexer it will return null, even when a parent property exists. Its nice to have that quick-fail, but I think we can only do so when it has neither a return value or a parameter:
对于当今的 .NET,我相信以下内容与 Marc 的答案相同,但更简洁,而且可能更高效。 我可能错过了什么。
For present day .NET, I believe the following is equivalent to Marc's answer but more concise and maybe a slight bit more efficient. I may have missed something.
使用的技巧是 BindingFlags.DeclaredOnly 和 IsSpecialName
The trick to play with is BindingFlags.DeclaredOnly and IsSpecialName