Earlier I posted about some extensions I did for Silverlight handling INotifyPropertyChanged and helpers for DependencyProperties. Recently I've had a couple of request to release a downloadable source with samples of their use. Since the original posts (found here and here), I've refined them a little bit and worked out some quirks that was left in the originals.
So, why should one use these kind of extensions and what do they solve?
INotifyPropertyChanged and creating DependencyProperties rely on the usage of literals. When for instance notifying the PropertyChanged event with a change on a particular property, the argument one passes in is the literal holding the name of the property. This is bad for at least a couple of reasons:
- Refactoring goes out the window – renaming the property means renaming the literals by hand
- Obfuscation – if one were to obfuscate the code, literals will still stay the same but your propertynames will change – your code is broken
I've wrapped it all in a nice download with both a Silverlight and a WPF version of the code (actually pretty much the same code, you'll find #if(SILVERLIGHT) #else #endif statements where specifics are needed). Also in the download, you'll find a Silverlight sample with a usercontrol implementing a dependencyproperty and a data object using the INotifyPropertyChanged extensions. In addition to this, there are a few other nifty helper classes and extensions for other aspects of both Silverlight and WPF development. Hope you'll find it handy.
The download can be found here.
Any reason why you are not using the ExpressionExtensions in the NotificationExtensions class?
Any reason why you are not using the ExpressionExtensions in the NotificationExtensions class?
Also, some comments in the code might have been nice :p
Also, some comments in the code might have been nice :p
All the extensions are in fact from different projects, I just assembled them all without looking over the code before posting it to my blog. A good point though, thanks!
Comments, whats that?
In fact, I should go over the code and make it so comments aren’t needed and refactor the code use the ExpressionExtensions. Tidy tidy..
I’ll see if I get the time to do it in the near future.
That would be totally sweet. Would be a lot easier to learn from that code as well =)
A Question: Some places I’ve seen this being used:
var m = property.Body as MemberExpression;
var name = m.Member.Name;
What is the reason why you have all of this:
var lambda = expression as LambdaExpression;
MemberExpression memberExpression;
if (lambda.Body is UnaryExpression)
{
var unaryExpression = lambda.Body as UnaryExpression;
memberExpression = unaryExpression.Operand as MemberExpression;
}
else
{
memberExpression = lambda.Body as MemberExpression;
}
var constantExpression = memberExpression.Expression as ConstantExpression;
var propertyInfo = memberExpression.Member as PropertyInfo;
var name = propertyInfo.Name;
Is it more general or safer or something? I don’t understand everything there, so to me it’s just "short code vs long code", but I’m sure there are some very good reasons.
Value types are special case – they are UnaryExpressions.
And in the UnaryExpression is the operand that represents the member.
I’m not sure why it has been designed this way by Microsoft, but I guess there is a good reason for it. 🙂
Value types are special case – they are UnaryExpressions.
And in the UnaryExpression is the operand that represents the member.
I’m not sure why it has been designed this way by Microsoft, but I guess there is a good reason for it. 🙂
So when sending in a property which is of type int or bool, the shorter way would fail? Or only if you sent in for example a public field of type int instead of a property?
So when sending in a property which is of type int or bool, the shorter way would fail? Or only if you sent in for example a public field of type int instead of a property?