(EntityDataSource.DomainContext as REIContext).Entity.Add(...)
used to update the DataGrid however, it no longer does this in the July CTP.
I have read the documentation and the above is exactly what is described in the RiaServicesOverviewPreview.pdf (pg 76). Am I missing something or is this a bug?
This change was intentional and you are correct that the behavior changed with the July 2009 Preview.
Previously, the DomainDataSource would latch onto and expose any entity matching the entity type that it had loaded. So, if you asked it to load Products,
and then you added a Product to the DomainContext’s Products list, the new product would show up in the DomainDataSource’s data. While this worked for some scenarios, it broke down in others.
For example, if you loaded Employees and included their Managers (who are also Employees) in the results, the list of data you’d see would actually be the
employees and managers, unioned together. If you had filtered the employee list to only see employees with the last name starting with “Y” you would see all of their managers in the list too, regardless of the last name filter.
In order to address this bug, we had to make a change to the DomainDataSource’s behavior such that it will only display entities that “it knows about.” This
means that any top-level entity that came back from a Load operation will be displayed, or any entities that are added through the DomainDataSource.DataView using the IEditableCollectionView interface.
When you call ((IEditableCollectionView)DomainDataSource.DataView).AddNew(), it will create a new entity matching the type that was loaded, and return it. Then
you can initialize the entity with property values, and call ((IEditableCollectionView)DomainDataSource.DataView).CommitNew(). This will add the entity to the DomainContext’s EntityList as well as to the DomainDataSource’s Data/DataView.
I hope this helps. I'll check the RiaServicesOverviewPreview.pdf document to see if we need to update the documentation to reflect this change.
Sorry for the inconvenience.
I ran into this same thing and with Jeff's help got things rolling earlier today. I just blogged about it here http://blog.davidyack.com/journal/2009/7/21/ria-services-domaindatasourcedata-not-updating.html and
I also included a few helper methods I created to avoid all the casting. I also combined the CommitNew / CommitEdit methods as well as the Cancels in the helper methods because they seemed to require too much thinking for the average use. I might change
my thinking once more docs are available, but I'd be curious to here some of the scenarios where you would want them separate.
Read my blog http://blog.davidyack.com
New Silverlight 3 Book - http://www.silverlightjumpstart.com
This looks like as good a place as any to say I would like to see the actual object behind IEditableCollectionView exposed publically. I don't use the DDS since it doesn't work well with my program structure (heavily MVVM and Prism2) and PagedCollectionView
does a pretty good job but I can't add new entities directly to the PagedCollectionView the way that EntityCollectionView can.
(I think it is EntityCollectionView, I don't have to right machine at the moment to check.)
Cool -- glad you said it Colin. We are looking at doing that, having a concrete class that implements the relevant interfaces, and returning an instance of that, instead of an instance of the internal EntityCollectionView class.
We're also considering adding functionality above and beyond the interface implementations to make Add/Remove/Edit simpler. So please let us know what you'd like to see there. In fact, I'll toss out a blog post to solicit suggestions.
@ColinBlair - we've been trying out a few ideas that use MVVM where it makes sense but still are able to leverage DDS where it has strengths. I'm not convinced there's not some level of co-existance possible and that using MVVM means never use a DDS
Read my blog http://blog.davidyack.com
New Silverlight 3 Book - http://www.silverlightjumpstart.com
@ColinBlair - we've been trying out a few ideas that use MVVM where it makes sense but still are able to leverage DDS where it has strengths. I'm not convinced there's not some level of co-existance possible and that using MVVM means never use a DDS
There can be co-existance, I proved that to myself back in December when I faked out the DDS by having my ViewModel inherit from DomainContext which then passed the load commands to the generated DomainContext from the DomainService. It was a very tortured
hack (the two major methods that the DDS calls on DomainContext are not virtual so I couldn't override them) but as a proof of concept it showed that a coexistance is possible. Nikhil blogged about doing a variant of the DDS which doesn't require the DomainContext
but I haven't heard anything about that lately. I think the variant EntityCollectionView that Jeff is talking about is a good first step toward integrating the DDS concept with MVVM but I think it is also something that needs a lot of discussion.
Since it has been so long since I last posted about this, I went back through DomainDataSource to see if anything had changed since I last poked around. What I found was that the DDS only calls DomainContext.HasChanges, DomainContext.Load, DomainContext.RejectChanges,
and DomainContext.SubmitChanges. Other than the code trying to find the query method by name there is no other dependency between the DDS and the DomainContext. Interestingly enough, the Load and SubmitChanges method being called by the DDS are now virtual
so it would be a lot easier to recreate my old proof of concept as long as RejectChanges and HasChanges aren't needed.
My belief is that if the DDS was refactored to require an IDomainContext (HasChanges, Load, RejectChanges, SubmitChanges) instead of DomainContext and a new dependency property was added so that we can provide the query method itself directly to the DDS
through binding instead of just the name then the problems that the MVVM backers have with the DDS would go away.
narayans
Member
38 Points
32 Posts
July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 17, 2009 07:31 PM | LINK
I have the following DomainDataSource and DataGrid:
<
ria:DomainDataSource x:Name="EntityDataSource" LoadSize="20" AutoLoad="True"> <ria:DomainDataSource.DomainContext> <app:REIContext/> </ria:DomainDataSource.DomainContext> </ria:DomainDataSource><
local:DataGrid Name="EntityDataGrid" ItemsSource="{Binding Data, ElementName=EntityDataSource}" AutoGenerateColumns="False" IsReadOnly="True" />With the May CTP, Calling
(EntityDataSource.DomainContext as REIContext).Entity.Add(...)
used to update the DataGrid however, it no longer does this in the July CTP.
I have read the documentation and the above is exactly what is described in the RiaServicesOverviewPreview.pdf (pg 76). Am I missing something or is this a bug?
JeffHandley
Participant
766 Points
147 Posts
Microsoft
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 21, 2009 10:03 PM | LINK
This change was intentional and you are correct that the behavior changed with the July 2009 Preview.
Previously, the DomainDataSource would latch onto and expose any entity matching the entity type that it had loaded. So, if you asked it to load Products, and then you added a Product to the DomainContext’s Products list, the new product would show up in the DomainDataSource’s data. While this worked for some scenarios, it broke down in others.
For example, if you loaded Employees and included their Managers (who are also Employees) in the results, the list of data you’d see would actually be the employees and managers, unioned together. If you had filtered the employee list to only see employees with the last name starting with “Y” you would see all of their managers in the list too, regardless of the last name filter.
In order to address this bug, we had to make a change to the DomainDataSource’s behavior such that it will only display entities that “it knows about.” This means that any top-level entity that came back from a Load operation will be displayed, or any entities that are added through the DomainDataSource.DataView using the IEditableCollectionView interface.
When you call ((IEditableCollectionView)DomainDataSource.DataView).AddNew(), it will create a new entity matching the type that was loaded, and return it. Then you can initialize the entity with property values, and call ((IEditableCollectionView)DomainDataSource.DataView).CommitNew(). This will add the entity to the DomainContext’s EntityList as well as to the DomainDataSource’s Data/DataView.I hope this helps. I'll check the RiaServicesOverviewPreview.pdf document to see if we need to update the documentation to reflect this change. Sorry for the inconvenience.
Thanks,Jeff Handley
DomainDataSource
narayans
Member
38 Points
32 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 21, 2009 10:37 PM | LINK
Makes perfect sense. I implemented the above and everything works.
For anyone else having this issue, IEditableCollectionView is in the System.Windows.Data assembly.
Thanks Jeff - for the solution and the underlying explanation.
Narayan
MrDave
Member
74 Points
39 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 21, 2009 11:29 PM | LINK
I ran into this same thing and with Jeff's help got things rolling earlier today. I just blogged about it here http://blog.davidyack.com/journal/2009/7/21/ria-services-domaindatasourcedata-not-updating.html and I also included a few helper methods I created to avoid all the casting. I also combined the CommitNew / CommitEdit methods as well as the Cancels in the helper methods because they seemed to require too much thinking for the average use. I might change my thinking once more docs are available, but I'd be curious to here some of the scenarios where you would want them separate.
Read my blog http://blog.davidyack.com
New Silverlight 3 Book - http://www.silverlightjumpstart.com
ColinBlair
All-Star
29951 Points
5034 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 12:05 AM | LINK
This looks like as good a place as any to say I would like to see the actual object behind IEditableCollectionView exposed publically. I don't use the DDS since it doesn't work well with my program structure (heavily MVVM and Prism2) and PagedCollectionView does a pretty good job but I can't add new entities directly to the PagedCollectionView the way that EntityCollectionView can.
(I think it is EntityCollectionView, I don't have to right machine at the moment to check.)
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services
JeffHandley
Participant
766 Points
147 Posts
Microsoft
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 12:13 AM | LINK
Cool -- glad you said it Colin. We are looking at doing that, having a concrete class that implements the relevant interfaces, and returning an instance of that, instead of an instance of the internal EntityCollectionView class.
We're also considering adding functionality above and beyond the interface implementations to make Add/Remove/Edit simpler. So please let us know what you'd like to see there. In fact, I'll toss out a blog post to solicit suggestions.
DomainDataSource
JeffHandley
Participant
766 Points
147 Posts
Microsoft
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 12:43 AM | LINK
Got the blog post out: http://jeffhandley.com/archive/2009/07/21/domaindatasource-dataview.aspx
DomainDataSource
MrDave
Member
74 Points
39 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 01:34 AM | LINK
@ColinBlair - we've been trying out a few ideas that use MVVM where it makes sense but still are able to leverage DDS where it has strengths. I'm not convinced there's not some level of co-existance possible and that using MVVM means never use a DDS
Read my blog http://blog.davidyack.com
New Silverlight 3 Book - http://www.silverlightjumpstart.com
ColinBlair
All-Star
29951 Points
5034 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 02:40 AM | LINK
There can be co-existance, I proved that to myself back in December when I faked out the DDS by having my ViewModel inherit from DomainContext which then passed the load commands to the generated DomainContext from the DomainService. It was a very tortured hack (the two major methods that the DDS calls on DomainContext are not virtual so I couldn't override them) but as a proof of concept it showed that a coexistance is possible. Nikhil blogged about doing a variant of the DDS which doesn't require the DomainContext but I haven't heard anything about that lately. I think the variant EntityCollectionView that Jeff is talking about is a good first step toward integrating the DDS concept with MVVM but I think it is also something that needs a lot of discussion.
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services
ColinBlair
All-Star
29951 Points
5034 Posts
Re: July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
Jul 22, 2009 06:48 PM | LINK
Since it has been so long since I last posted about this, I went back through DomainDataSource to see if anything had changed since I last poked around. What I found was that the DDS only calls DomainContext.HasChanges, DomainContext.Load, DomainContext.RejectChanges, and DomainContext.SubmitChanges. Other than the code trying to find the query method by name there is no other dependency between the DDS and the DomainContext. Interestingly enough, the Load and SubmitChanges method being called by the DDS are now virtual so it would be a lot easier to recreate my old proof of concept as long as RejectChanges and HasChanges aren't needed.
My belief is that if the DDS was refactored to require an IDomainContext (HasChanges, Load, RejectChanges, SubmitChanges) instead of DomainContext and a new dependency property was added so that we can provide the query method itself directly to the DDS through binding instead of just the name then the problems that the MVVM backers have with the DDS would go away.
Upshot Blog
ColinBlair on Twitter
MVVM and RIA Services