I just starting on WPF with MVVM, so forgive any misconceptions. I have a model (not a view model but the actual model) that has many List inside classes that are in other List making trees of data.
Important, the data should be XML Serializabled, currently there is no problem doing that with regular properties and List.
The View Model of this class is taking a lot more work than I expected and I’m thinking on converting some or maybe all of the List to ObservableCollections, what are the pros and cons of that?
Also, what would be best in a “bindable model”, NotifyPropertyChange or DependencyProperties? I think there would be some memory gains with DependencyProperty since many objects will use default values on most of the properties, what about performance in general, and has it any problems with serialization?
Regards,
There is a bit more overhead in
ObservableCollection<T>when compared toList<T>, but it does make it easier as data binding directly to your model collections will work.I would not use DependencyProperties within your model. This is taking a dependency on the WPF libraries, and very platform specific. If you want to be able to data bind directly to your model, implementing
INotifyPropertyChangedis a reasonable approach.However, you really should stop and take a minute before making any of these changes. If you’re changing your model classes primarily to use them in your View, you’re violating the basic principles of MVVM (and most other architectural patterns). One of the main goals here is that your Model is unaware of the presentation layer being used – this makes it more flexible in the future, as you can change presentation layers without changing your model at all.