Comments on: How to avoid passing property names as strings using C# 3.0 Expression Trees

By: knocte

knocte — Fri, 26 Nov 2010 13:56:00 +0000

Is this different from this solution[1]?

If yes, is it better?

I wonder if you could include it in some helper library so we can use it more easily. How about Cadenza? (The former Mono.Rocks) Can you commit it there?

[1] http://blogs.microsoft.co.il/blogs/arik/archive/2010/11/17/no-more-magic-strings-presenting-string-of.aspx

By: air jordan 24

air jordan 24 — Wed, 07 Jul 2010 10:46:27 +0000

Hhe article's content rich variety which make us move for our mood after reading this article. surprise, here you will find what you want! Recently, I found some wedsites which commodity is colorful of fashion. Such as that worth you to see. Believe me these websites wont let you down. hip hop clothes

By: mitchdcba

mitchdcba — Wed, 28 Apr 2010 13:46:10 +0000

……..

By: Ivan Zlatev

Ivan Zlatev — Sun, 13 Dec 2009 18:22:05 +0000

You are right. I have updated the post with support for the Convert expression so that implicit and explicit casting are supported as well.

By: henon

henon — Sun, 13 Dec 2009 17:43:27 +0000

I improved it to work with valuetype properties too (which isn't the case with yours because of boxing) and added unit tests. here is what I got:

using System;
using System.Diagnostics;
using System.Linq.Expressions;
using System.Reflection;

public static class ExpressionsExtension
{
///

/// Derives the name of a property from the given lambda expression and returns it as string.
///
/// Example: DateTime.Now.DerivePropertyNameFromExpression(s => s.Ticks) returns "Ticks"
///

/// a lambda expression of the type x => x.PropertyName
///
public static string DerivePropertyNameFromExpression(this T type, Expression> expression)
{
var property_ref_expr = expression.Body;
Debug.Assert(property_ref_expr != null);
var member_expr = property_ref_expr as MemberExpression;
if (member_expr == null || member_expr.Member.MemberType != MemberTypes.Property)
throw new ArgumentException("No property reference expression was found.", "expression");
return member_expr.Member.Name;
}
}

#if DEBUG

namespace Test
{
using NUnit.Framework;

[TestFixture]
public class ExpressionExtensionTest
{
[Test]
public void TestNameDerivationFromValueTypeProperty()
{
Assert.AreEqual("Ticks", DateTime.Now.DerivePropertyNameFromExpression(s => s.Ticks));
}

[Test]
public void TestNameDerivationFromReferenceTypeProperty()
{
Assert.AreEqual("Parent", new ExampleClass().DerivePropertyNameFromExpression(s => s.Parent));
}

public class ExampleClass
{
public ExampleClass Parent { get; set; }
}
}
}

#endif

By: Ivan Zlatev

Ivan Zlatev — Sun, 13 Dec 2009 10:22:05 +0000

You are right. I have updated the post with support for the Convert expression so that implicit and explicit casting are supported as well.

By: henon

henon — Sun, 13 Dec 2009 09:43:27 +0000

/// Derives the name of a property from the given lambda expression and returns it as string.
///
/// Example: DateTime.Now.DerivePropertyNameFromExpression(s => s.Ticks) returns "Ticks"
///

By: Asbjørn Ulsberg

Asbjørn Ulsberg — Mon, 07 Dec 2009 07:36:46 +0000

C# 3.0 Expression Trees are brilliant. Fluent NHibernate is entirely built around them, yielding extremely terse and readable code that's a walk in the park to refactor. Excellent stuff!

By: migueldeicaza

migueldeicaza — Sat, 05 Dec 2009 14:17:48 +0000

This is a brilliant hack.

By: Alan

Alan — Fri, 04 Dec 2009 21:22:11 +0000

You could probably avoid some of the performance pain (if it actually turns out to be a bottleneck) with some clever caching of the expression tree and/or its result. Lazy sounds like the ideal candidate here – you'll compute your string name once and then be able to re-use it for free as many times as you want.