aL_ said:
vesuvius said:
*snip*

well even if you use stored procedures you still need to call them from somewhere in your code, thats where the repository comes in, so that you can just swap out those calls for mocked versions.. imo mvvm has very little to do with using stored procedures or not, thats part of the model, not the viewmodel..

who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

remember, the viewmodel is just the glue that binds the ui to the model implementation, in this case the dataset [or poco or EF or linq2sql or whatever]

-> who says you have to ignore the dataset change tracking? just stick datasets in your viewmodel and use INotifyPropertyChanged Smiley you dont have to use ObservableCollection at all (although it may be faster to do so) you could even implement your own thin generic wrapper based on INotifyCollectionChanged around datasets and raise the appropriate events as they are raised by the dataset..

You don't need to do that yourself, you could simply use BindingListCollectionView to wrap the DataView, and expose it as a property on the ViewModel, BindingListCollectionView will help adapting the Windows Forms' IBindingList contract into WPF's INotifyCollectionChanged contract.

Disclaimer, binding to ADO.NET data is the buggiest piece of feature inside WPF' data binding subsystem, please take my words serious, since I've done a lot of debugging on ADO.NET binding in WPF:)

Zhou Yong