I am not a Microsoft employee, I have not even played a Microsoft employee on television. What follows is my own ideas on a what part of a future version of WCF RIA Services could look like.
What we know
As of this writing, MVVM friendly DomainDataSource is the fifth most requested feature for the next version of WCF RIA Services. According to Jeff Handley, this is what he envisions for this feature:
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."
Why this matters
Over the last two posts, I have been discussing ways that a ViewModel could present collection of Entities to the View. Of the options I presented only the PagedCollectionView is acceptable to me in the short term but in the long term there clearly has to be a better way. The other option which I hadn't previously mentioned is to build something new from scratch, an option that I have contemplated myself. The reason that I haven't is that I do not like duplicating logic that already exists and the fact that the PagedCollectionView and the EntityCollectionView already exist make me unlikely to want to write my own ICollectionView from scratch. To me, the best solution is to get the public EntityCollectionView that some of us have been talking about for a year now.
EntityCollectionView? What is that?
Outside of a few old blog entries from Jeff and Brad you probably haven't heard of the EntityCollectionView. The EntityCollectionView is everything that the PagedCollectionView isn't. It is strongly typed, it supports the Entity, it supports IEditableCollectionView against an EntitySet, it supports external delegates to implement adds, removes, and deletes, and finally there is a PagedEntityCollectionView that adds RIA Services integrated paging support. Unfortunately, the current EntityCollectionView is internal and can only be used by the DomainDataSource. It will take lots of time to properly refactor the DDS and get all of the interfaces fully implemented, time that simply didn't exist for the initial release of RIA Services. Anyone who has been following the development of RIA Services knows the DomainDataSource was probably the most actively modified component of RIA Services right up to the end. They would also know that the DomainDataSource also the most monolithic parts of RIA Services.
What we can gather from Jeff's above statement is that he wants to refactor the DomainDataSource to better match the rest of RIA Services itself. That means being more modular and being more programmer driven. For the rest of this post, I am going to discuss some scenarios that I think should be covered by the new classes:
In the previous post I had a link to an overview of the ICollectionView. One of the issues with most implementations of ICollectionView is that sorting is slow due to reflection issues. Another issue that is specific to RIA Services is that for loading data we have the EntityQuery but for the ICollectionView we have the Filter and the SortDescriptions. Having two different methods of doing the same thing would be annoying. What would be better is the ability to supply the EntityQuery to the EntityCollectionView. This would allow the same EntityQuery to be used for the load and the filter.
The unknown here is if the ICollectionView.Filter and ICollectionView.SortDescriptions should still be implemented or not. The SortDescriptions could probably be derived from the EntityQuery (and the reverse) but the Filter is tricky.
Read Only Mode and user providable methods for insert and delete
The ViewModel needs to be the owner of the EntityCollectionView and control of insert, deleting, and paging. In many cases, the EntityCollectionView can be left to default functionality but in others the ViewModel needs to provide the actual logic. A good example of this would be to look at how the EntityCollection is implemented in your generated code. That shows an example of how add and delete logic can be externally supplied.
Unfortunately, this does mean that the constructor for the EntityCollectionView may end up being rather complex. It is possible that some kind of "controller" object may be needed that can be supplied during construction and held onto by the ViewModel.
One of the biggest problems with the PagedCollectionView is that it is not strongly typed. The problem here is that there may be other logic within the ViewModel that wants to use the same CollectionView that the View itself is seeing. Without strong typing, this requires lots of type casting which is, at best, annoying.
Yes, the need for paging is obvious, but it also important to keep in mind the type of paging that is needed. It is possible that in some situations that the paging is being done only against already loaded entities. Much like with the update and the delete, we need to be able to override the paging so that the ViewModel can override.
This has been an interested three part series for me as it helped clarify some ideas that I have had for awhile. For this post in particular, if you have any scenarios that you think the EntityCollectionView needs to cover please let me know and I will see if I can modify the post to account for it.