And they worth diving in!
After looking at your elegant code I’ve realized how important Expressions
might be, and definitely want to spend some time learning more.
Also, when I have incorporated it in my application, I do not see it any
more “as largely "for jollies"”. I feel much more confident in biasness logic
layer now, than when the database fields (i.e. SQL LINQ properties) where
strings in my error reporting methods.
Since my original question was about getting names of the properties, I have
modified your code and introduced a delegate that returns object, so when
looking for a property name, I do not need to specify result type <TType,
TResult>, but just <TType>.
Actually, your code blows on such expressions, since Expression contains
Convert function that your code doesn’t expect ({x =>
Convert(x.cs_dt_received)}).
In the code below expression parsing is 'hard wired' (just for
illustration), so the place for UnitaryExpression is visible.
static class MemberUtil
{
public delegate object PropertyNameDeletgate<T>(T x);
public static string GetPropertyName<T(Expression
<PropertyNameDeletgate<T>member)
{
return ((MemberExpression) ((Expression) ((UnaryExpression)
member.Body).Operand)).Member.Name;
//return MemberUtil.ParseMemberInfo(member).Name;
}
}
"Marc Gravell" wrote:
Looks a bit scary, but it does the job.
That phrase pretty-much describes most manual uses of Expression - a
very confusing subject indeed! For info, though: it looks scary, but
it gets easier with a little practice - you just need to take a very
deep breath before diving in ;-p
Marc
