views:

567

answers:

3

New to MVVM so please excuse my ignorance.

I THINK i'm using it right but I find my ViewModel has too many of these:

RaisePropertyChanged("SomeProperty")

Every time I set a property I have to raise that damned property changed.

I miss the days where I could just go:

public int SomeInteger { get; private set;}

These days I have to stick the "RaisePropertyChanged" in everywhere or my UI does not reflect the changes :(

Am I doing it wrong or are other people getting annoyed with the excessive number of magic strings and old school property setters?

Should I be using dependency properties instead? (I doubt that would help the code bloat anyway)

Despite these problems I still think MVVM is the way to go so I guess that's something.

+5  A: 

Take a look at this http://stackoverflow.com/questions/954198/what-is-the-best-or-most-interesting-use-of-extension-methods-youve-seen/2339904#2339904.

It describes an extension method and a helper method that my Model and ViewModel classes use to enable the following strongly typed (no magic string) properties.

private string _name;
public string Name
{
    get { return _name; }
    set { this.NotifySetProperty(ref _name, value, () => this.Name); }
}

This is about as simple as I think it can get. Hope it helps.

Enigmativity
Thanks. kinda glad to know I wasn't the only one having issues.
vidalsasoon
+1  A: 

It helps to look at things from a different perspective: those are not complicated .NET properties, but simplified dependency properties.

Bindable properties of a view model in WPF are not identical to .NET properties, instead it is a kind of key-value store. If you want light-weight alternative to DependencyObject, you have an ability to implement this key-value store just buy calling certain function in setters - not bad, actually. Far from ideal too, of course, but your point of view is certainly unfair.

ima
+5  A: 

You could use PostSharp's NotifyPropertyChanged attribute. Then all you have to do is to put an attribute on the class and that's it. E.g.:

[NotifyPropertyChanged]
public class MyClass 
{
    public string MyProperty { get; set; }
}
PL
interesting! curious about the overhead though...
vidalsasoon
There's no runtime overhead since PostSharp simply modifies the compiled class and injects exact same code you write manually. There's a small build time overhead but I found it negligible.
PL