MVVM friendly DomainDataSource
Greg Hollywood commented
Here is what I would like to see with the DDS:
Make a "sister" version of it that is not a Control, but just a class. The purpose being to use it directly in code, not in xaml. Then expose overrides and such so that one could subclass it and make modifications to fit ones exact needs. I tried to subclass and modify it, but there is nothing to override except the Control stuff.
I know that you can already use the DDS in code only and get most of the functionality out of it. However, I find I can't use it in more advanced scenerios to do things such as Prefetching. (I know you can set the load size, but that still doesn't allow the control to always be one page ahead of the user.)
I think that having a second sister class like this would be beneficial, as then the code only use of it would be much better documented. I long avoided the use of the DDS as every sample I saw used it only in xaml. Which is not where I like my data access code to be. But it is in fact very useful in code only, but the perception is that it is xaml only. A code-only class would solve that issue.
I would certainly use it more if this were the case.
The DomainDataSource works pretty well as is on ViewModels if testability is not your #1 concerns :)
I really don't understand how else would people use this control for enterprise development other than encapsulating it in their ViewModels.
I would love this feature. I thought it might already be there and was trying for 1/2 a day to figure out how to get it.
If anything, allow me to just set a non-DomainContext DataSource on it and get all the other functionality that comes with it.
Either way, it would be nice. I'm not exposing the DataContext to my XAML. Heck, I don't even expose it to my ViewModels. I hide it behind an interface for unit testing.
Jeff Handley commented
What I have been imagining is taking the existing DomainDataSource feature and splitting it up into a set of components that can be used selectively from a ViewModel, or used all together as the DomainDataSource control that you know.
The PagedEntityCollectionView class would likely become public, as well as the EntityCollectionView. I'd also like to break the data loading functions out so that the logic used to submit the requests for loads and the response handling could be utilized from a ViewModel. The DomainDataSource manages situations such as hierarchical data and there's a lot of code involved to replicate that in a ViewModel--I'd love to see those functions exposed for easy consumption without using the DomainDataSource control in the UI.
So I really see this item as a way to get the features of the DomainDataSource out of the DomainDataSource, and available to developers to use how they wish.
What does MVVM friendly DomainDataSource mean? It means getting access to the built in paging support from inside the ViewModel. It means being able to use the DomainDataSource like a strongly typed, RIA Services compatible version of the PagedCollectionView.