5

I am writing a desktop application in C# using the MVVM pattern with an Entity Framework model. I tend to use DependencyProperties in my VM's and have come to (generally) prefer this system over implementing INotifyPropertyChanged. I would like to keep things consistent. My VM accesses the Entities in the Model and I have managed to keep things pretty separate - the View has no knowlege of the VM except for binding and command names and the Model has know knowlege of the VM.

Using INotifyPropertyChanged in the VM, it seems pretty easy to update the Entities in the Model:

public string Forename
    {
        get { return CurrentPerson.Forename; }
        set
        {
            if (Forename != value)
            {
                CurrentPerson.Forename = value;
                NotifyPropertyChanged("Forename");
            }
        }
    }

...where CurrentPerson is a Person object auto-created by the Entity Data Model. There is therefore no private field created specifically to store the Forename.

With DependencyProperties, it appears that I would have to create a DP, add the default Property, using GetValue and Setvalue and then use the PropertyChangedCallback in order to update the CurrentPerson Entity. Calling a callback in this situation appears to be adding overhead for the sake of being consistent with my other VM's.

The question is therefore whether one or other of these methods is the way I should do things? In this instance, should I use a DependencyProperty or INotifyPropertyChanged? One thing that should be pointed out is that this will potentially be a very large scale project (with plugins and a lot of database accesses from different machines) and that everything really should be as reusable, and the modules as "disconnected", as possible.

AJ.
  • 1,621
  • 1
  • 10
  • 23
  • What is a benefit of using dependency properties in view model? In other words - what additional value it brings that `INotifyPropertyChanged` does not offer. – Ladislav Mrnka Sep 16 '12 at 19:51
  • I'm looking for good speed and the nice binding features that come with DP's. Bear in mind that I'm binding direct to the DP's with XAML in my View. There are also likely to be frequent property value changes. From the references I have previously found, for speed with binding, DP's are the way to go. There's also consistency with the rest of my design. However, none of this is any good if it is negated by all those callbacks going on with separate amendments to the Entity objects. – AJ. Sep 16 '12 at 20:05

1 Answers1

2

I would recommend using INotifyPropertyChanged instead of DependencyProperty. The main reason I stay away from DependencyProperty in ViewModels is because the DependencyProperty is located in WindowsBase.dll. This ties you to the Windows UI a bit too much (at least IMHO).

Using the INotifyPropertyChanged is a lot easier to maintain since it allows the various plugins to implement it the way they want. If you force Dependency Properties, all viewmodels need to inherit from DependencyObject.

See this article for more details about the use of INotifyPropertyChanged and DependencyProperty: http://kentb.blogspot.com/2009/03/view-models-pocos-versus.html

Another supporting answer: https://stackoverflow.com/a/783154/27669

Community
  • 1
  • 1
kevindaub
  • 3,293
  • 6
  • 35
  • 46
  • Thanks. I think INotifyPropertyChanged is going to be the way to go, although event with the various safeguards to using "Magic Strings" in INotifyPropertyChanged, I still find DP's more elegant. The two main reasons I am coming to this point of view are: 1) State Duplication with DP's and 2) The fact that I sometimes need to change the entire object state, and I can simply do this with PropertyChanged(null). Thanks for the answer and references. – AJ. Sep 16 '12 at 20:30
  • The coupling to Windows UI can be a MAJOR issue .. Just fixed a project where the same dlls were used for a web service but the Dependency Property insisted it runs on the UI thread which is rather tricky in a multithreaded web service . This architectural flexibility ( ie lack of tight coupling to Windows GUI in your Entity Dlls) is far more important than elegance for the GUI. – user1496062 Feb 04 '14 at 22:25