Prev: [^o]o{1,3}[^o] is wrong :-/
Next: ArgumentException unhandled: OleAutDate
From: Konstantin on 20 May 2010 08:28
static class PropertyName<TClass>
{
public static string Get<TPropertyReturnValue>(Expression<Func<TClass, TPropertyReturnValue>> expr)
{
var memberExpr = expr.Body as MemberExpression;
if (memberExpr == null)
throw new ArgumentException("Expression must contain the only member access operation", "expr");
return memberExpr.Member.Name;
}
}

class MyClass
{
public int MyProperty { get; set; }
}

// ...

PropertyName<MyClass>.Get(x => x.MyProperty); // returns "MyProperty"



Peter Duniho wrote:

Re: Refactor-safe Property Access Using Reflection?
17-Aug-09

How tied to the original data object is your decorator? Do you _have_ to
use reflection? Or is that a convenience, so that you do not have to
explicitly type mappings between strings and actual properties?

If the latter, then it seems to me that one alternative would be to give
up on the convenience (which is costing you in reflection overhead
anyway), and just do the explicit mapping. It could even be as simple as
a big switch (which the compiler will translate into something efficient
anyway). Then, since your decorator is explicitly calling named members
of the decorated class, refactoring catches it.

If you are trying to use the same decorator class for all decorated types,
and thus reflection is more of a necessity than a convenience, then I
do not see an easy way around that. If your decorated types can change and
you do not want to have to go back and fix up all the string-based
accessors through decorators, it seems to me you will have to provide for a
separate mechanism to do the mapping. Either strictly string-based, which
provides zero tie-in to the refactoring tools, or something that _is_
inherently tied to the named members of the decorated classes, in which
case it begs the question: if you have to tie something to the decorated
class, why not just make that the decorator itself?

I suppose yet another alternative would be to use a custom code attribute
to mark the properties with the mapped name(s). But if you have to embed
the client-side name used for the properties in the data object class
anyway, via an attribute, then the question that is begged _there_
becomes: why rename the property at all, if it is going to cause such a
headache and require this additional complexity?

If you have a concise-but-complete code example that clearly illustrates
the relationships between your classes here, that might help. If you can
include a link to one or more of the examples you referred to in which
"developers are using
expression trees to make refactoring and reflection go hand-in-hand", that
might help too. I am not really sure what you mean there.

Pete

Previous Posts In This Thread:

On Monday, August 17, 2009 6:43 PM
Peter Duniho wrote:

Re: Refactor-safe Property Access Using Reflection?
How tied to the original data object is your decorator? Do you _have_ to
use reflection? Or is that a convenience, so that you do not have to
explicitly type mappings between strings and actual properties?

If the latter, then it seems to me that one alternative would be to give
up on the convenience (which is costing you in reflection overhead
anyway), and just do the explicit mapping. It could even be as simple as
a big switch (which the compiler will translate into something efficient
anyway). Then, since your decorator is explicitly calling named members
of the decorated class, refactoring catches it.

If you are trying to use the same decorator class for all decorated types,
and thus reflection is more of a necessity than a convenience, then I
do not see an easy way around that. If your decorated types can change and
you do not want to have to go back and fix up all the string-based
accessors through decorators, it seems to me you will have to provide for a
separate mechanism to do the mapping. Either strictly string-based, which
provides zero tie-in to the refactoring tools, or something that _is_
inherently tied to the named members of the decorated classes, in which
case it begs the question: if you have to tie something to the decorated
class, why not just make that the decorator itself?

I suppose yet another alternative would be to use a custom code attribute
to mark the properties with the mapped name(s). But if you have to embed
the client-side name used for the properties in the data object class
anyway, via an attribute, then the question that is begged _there_
becomes: why rename the property at all, if it is going to cause such a
headache and require this additional complexity?

If you have a concise-but-complete code example that clearly illustrates
the relationships between your classes here, that might help. If you can
include a link to one or more of the examples you referred to in which
"developers are using
expression trees to make refactoring and reflection go hand-in-hand", that
might help too. I am not really sure what you mean there.

Pete

On Tuesday, August 18, 2009 2:12 AM
kndg wrote:

Re: Refactor-safe Property Access Using Reflection?
Hi Travis,

If I understand your requirement correctly, instead embedding the string
directly in code, you need to pass your method with your property name.
I am not sure whether it can be done using Expression Tree or not, but it
can be done using reflection.

Just declare your PropertyInfo object on your class,

private static PropertyInfo[] properties = typeof(MyObject).GetProperties();

Then, pass the properties[0].Name to your SetValue method.
Take note that the array is indexed base on how you arrange your
properties.

Regards.

On Tuesday, August 18, 2009 5:15 AM
kndg wrote:

Re: Refactor-safe Property Access Using Reflection?
I am just find below article a nice read.

http://michaelsync.net/2009/04/09/silverlightwpf-implementing-propertychanged-with-expression-tree

On Tuesday, August 18, 2009 7:14 AM
jehugaleahs wrote:

Refactor-safe Property Access Using Reflection?
Hello:

I have been seeing a lot of cool examples where developers are using
expression trees to make refactoring and reflection go hand-in-hand. I
am wondering if a trick like that could be performed with properties.
I do not have much first-hand experience with expression trees.

In my system, we have GUI and non-GUI applications. I have a service
layer that returns data objects. When I attach my data objects to a
Windows Form, I decorate them to support INotifyPropertyChanged. The
decorator has methods for getting and setting property values of the
decorated data object.

I have a method that looks like this:

void SetValue<T>(string propertyName, T value) { ... }

This method goes into the decorated data object and sets it is
property. It then raises a PropertyChanged event (passing the property
name).

Now say I change my data object's property names. With the
implementation above, my decorator throws an exception because the
property cannot be found (because it is referring to the old name).

I was hoping to alleviate this by replacing my string with something
spiffy. I was wondering if anyone could think of a way to do it. We're
dealing with a user interface here, so performance is not that
important.

Thanks,
Travis

On Tuesday, August 18, 2009 7:14 AM
jehugaleahs wrote:

Re: Refactor-safe Property Access Using Reflection?
wrote:
to =A0
=A0
=A0
as =A0
=A0
s =A0
, =A0
and =A0
=A0
ich =A0
=A0
=A0
=A0
ed =A0
=A0
=A0
an =A0
=A0
t =A0

Yes. I have thought about calling the the underlying methods
explicitly and have allowed it to be done (raising PropertyChanged

On Saturday, August 22, 2009 2:29 AM
jehugaleahs wrote:

Re: Refactor-safe Property Access Using Reflection?
Ah. Now that is what I am talking about! So it could be done using an
expression tree. I am going to have to seriously look into this nifty
little feature.

All it costs is a delegate call. (p =3D> p.Name)

That is an awesome article. I am going to go play around for a while.


Submitted via EggHeadCafe - Software Developer Portal of Choice
Free Online Courses Available for Eggheadcafe.com Users
http://www.eggheadcafe.com/tutorials/aspnet/5261083e-6e03-4b25-8728-fc3cf6855293/free-online-courses-avail.aspx
 | 
Pages: 1
Prev: [^o]o{1,3}[^o] is wrong :-/
Next: ArgumentException unhandled: OleAutDate