The second most requested feature on our
WCF RIA Services Wish List is an MVVM-friendly DomainDataSource. The neat part about this request is that it means many different things to many different people. The challenge in addressing it is to figure out what are the most valuable
changes that will satisfy the greatest number of scenarios.
This is where I turn to you. I’d love to hear some opinions about what people think is important. For now, let’s keep the discussion constrained to two questions.
What are the two most important changes for us to make to the DomainDataSource to make it MVVM-friendly?
If those changes were made, would you use the DomainDataSource in your View Models?
I know there’s more on this topic to talk about, but let’s start slow.
----------
Starting with this
post, I plan to use my blog as a tool for looking deeper into this issue. Subscribe for a while if you're interested in how this topic evolves.
I am going to take a different tact here then I have been lately as I just remembered the solution we were kicking around in early 2009.
The most important change that you could make to the DomainDataSource would be to remove the direct reference to DomainContext. If the DDS, or some variant, could be designed that works against an interface and the property supplying it to the DDS could
be bound, then that would solve the request and yes, I would use it.
I don't know if I would use it? I think I need some more education on what its benefits are?
What does the DDS offer that the PagedCollectionView does not already offer?
I am guessing the management of the DomainContext, including Blendability support? This is a problem I have struggled with for several months now, and as a result built my own MVVM toolkit to address this.
If you want to take a look at what I did, here is a link to my project on CodePlex:
MVVM+S.
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.
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 get the feeling this is the prevailing sentiment. There are lots of useful things in the DDS that *can* be used in code. I most cases, the concern is whether they *should* be used in code.
Isn't this all part of the DomainContext? Is the benefit just simplicity since you can then add queries, ordering, paging to the view instead of in code on the DomainContext?
I do not see this as a big problem since we are generating a bit more code using MVVM pattern anyway. That being said, it would be great to have an ICollectionView that could handle the loading of the DomainContext.
The bigger challenge I see is the loading of multiple related entities. I struggle with adding too many [Include] attributes, and having too many query options on my domainservice exposed (just to include different items). My preference would be to have
a means to define includes from the client. The client is where I am figuring out what entities, and relationships to load. Not on the server. This is where I found the batching system helpful with the toolkit I pulled together.
Is this something you could add to a DDS for MVVM?
Hmm, since this thread hasn't kept to Kyle original "lets keep this simple" beginning, I will go ahead and expand on the issues a bit. The issue from a MVVM perspective is that the DDS combines two separate concerns into one. To make the DDS more friendly
to MVVM those two concerns need to be split.
The first concern is the View's concern. The View's job is to display data to the user. To do this, the view's designer may want to filter, order, and page data in different ways. The View doesn't care where the data is actually coming from, it just wants
the data.
The second concern is the ViewModel and Model. It is their job to know where the data is coming from and how to get it. When the View asks for a new page of data, does that page of data come from already loaded data or does a new load need to be sent to
the server? That is what they decide. What happens to the data that is not on the current page? What if that data was changed? Can we change pages with unsaved changes? There are the types of questions that the ViewModel needs to decide.
Currently the DDS manages both jobs. It exists inside the View but you tell it the name of the query in the DomainService. That is not something the View should know. When you change pages the DDS removes the old rows from the DomainContext. Again, not something
the View should be deciding. When there is a change anywhere in the DomainContext the DDS stops paging. Again, not something the View should be deciding.
The key difficult thing in all of this is generating the query to send back to the DomainService. I imagine the process working something like this:
DDS told to change to page 6 of data
DDS notifies ViewModel that it is changing pages (event allows for cancellation)
DDS filters, orders, and pages bound IEnumerable
DDS notifies ViewModel that it just changed pages
ViewModel checks the information in the PageChange event (page size, row count, etc) and based on whatever logic it has decides that it needs to load additional data and/or detach old data.
ViewModel calls DDS passing in an EntityQuery. DDS returns EntityQuery with the same filter, order, take, and skip information it is currently using on the bound IEnumerable
ViewModel loads the resulting EntityQuery
Based on ICollectionChanged, new rows show up in current DDS page
kylemc
Contributor
7243 Points
1147 Posts
Microsoft
What is an MVVM-friendly DomainDataSource?
Sep 01, 2010 05:54 PM | LINK
The second most requested feature on our WCF RIA Services Wish List is an MVVM-friendly DomainDataSource. The neat part about this request is that it means many different things to many different people. The challenge in addressing it is to figure out what are the most valuable changes that will satisfy the greatest number of scenarios.
This is where I turn to you. I’d love to hear some opinions about what people think is important. For now, let’s keep the discussion constrained to two questions.
I know there’s more on this topic to talk about, but let’s start slow.
----------
Starting with this post, I plan to use my blog as a tool for looking deeper into this issue. Subscribe for a while if you're interested in how this topic evolves.
ColinBlair
All-Star
29787 Points
5012 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 01, 2010 07:11 PM | LINK
I am going to take a different tact here then I have been lately as I just remembered the solution we were kicking around in early 2009.
The most important change that you could make to the DomainDataSource would be to remove the direct reference to DomainContext. If the DDS, or some variant, could be designed that works against an interface and the property supplying it to the DDS could be bound, then that would solve the request and yes, I would use it.
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services
rposener
Member
9 Points
8 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 01, 2010 09:53 PM | LINK
I don't know if I would use it? I think I need some more education on what its benefits are?
What does the DDS offer that the PagedCollectionView does not already offer?
I am guessing the management of the DomainContext, including Blendability support? This is a problem I have struggled with for several months now, and as a result built my own MVVM toolkit to address this.
If you want to take a look at what I did, here is a link to my project on CodePlex: MVVM+S.
Casimodo72
Participant
1054 Points
464 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 04, 2010 01:34 AM | LINK
Executing queries, order-by's, groupings and filtering on the server side.
Regards,
Kasimier
sladapter
All-Star
43609 Points
7910 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 04, 2010 02:50 AM | LINK
And be able to set LoadSize and PageSize to do load on demand plus caching already loaded data.
Software Engineer
Aprimo, Inc
Please remember to mark the replies as answers if they answered your question
Greg Hollywood
Member
92 Points
238 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 05, 2010 08:14 PM | LINK
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.
Greg
nk54
Member
92 Points
125 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 06, 2010 01:50 PM | LINK
:)
- Nk54 - French -
kylemc
Contributor
7243 Points
1147 Posts
Microsoft
Re: What is an MVVM-friendly DomainDataSource?
Sep 07, 2010 02:50 PM | LINK
I get the feeling this is the prevailing sentiment. There are lots of useful things in the DDS that *can* be used in code. I most cases, the concern is whether they *should* be used in code.
Thanks for the feedback.
rposener
Member
9 Points
8 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 07, 2010 02:50 PM | LINK
Isn't this all part of the DomainContext? Is the benefit just simplicity since you can then add queries, ordering, paging to the view instead of in code on the DomainContext?
I do not see this as a big problem since we are generating a bit more code using MVVM pattern anyway. That being said, it would be great to have an ICollectionView that could handle the loading of the DomainContext.
The bigger challenge I see is the loading of multiple related entities. I struggle with adding too many [Include] attributes, and having too many query options on my domainservice exposed (just to include different items). My preference would be to have a means to define includes from the client. The client is where I am figuring out what entities, and relationships to load. Not on the server. This is where I found the batching system helpful with the toolkit I pulled together.
Is this something you could add to a DDS for MVVM?
ColinBlair
All-Star
29787 Points
5012 Posts
Re: What is an MVVM-friendly DomainDataSource?
Sep 07, 2010 04:46 PM | LINK
Hmm, since this thread hasn't kept to Kyle original "lets keep this simple" beginning, I will go ahead and expand on the issues a bit. The issue from a MVVM perspective is that the DDS combines two separate concerns into one. To make the DDS more friendly to MVVM those two concerns need to be split.
The first concern is the View's concern. The View's job is to display data to the user. To do this, the view's designer may want to filter, order, and page data in different ways. The View doesn't care where the data is actually coming from, it just wants the data.
The second concern is the ViewModel and Model. It is their job to know where the data is coming from and how to get it. When the View asks for a new page of data, does that page of data come from already loaded data or does a new load need to be sent to the server? That is what they decide. What happens to the data that is not on the current page? What if that data was changed? Can we change pages with unsaved changes? There are the types of questions that the ViewModel needs to decide.
Currently the DDS manages both jobs. It exists inside the View but you tell it the name of the query in the DomainService. That is not something the View should know. When you change pages the DDS removes the old rows from the DomainContext. Again, not something the View should be deciding. When there is a change anywhere in the DomainContext the DDS stops paging. Again, not something the View should be deciding.
The key difficult thing in all of this is generating the query to send back to the DomainService. I imagine the process working something like this:
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services