Skip to main content
Home Forums Silverlight Programming WCF RIA Services July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data
9 replies. Latest Post by ColinBlair on July 22, 2009.
(0)
narayans
Member
38 points
19 Posts
07-17-2009 3:31 PM |
I have the following DomainDataSource and DataGrid:
<
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
138 points
33 Posts
07-21-2009 6:03 PM |
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.
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.
07-21-2009 6:37 PM |
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
74 points
39 Posts
07-21-2009 7:29 PM |
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.
ColinBlair
Contributor
6223 points
1,210 Posts
07-21-2009 8:05 PM |
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.)
07-21-2009 8:13 PM |
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.
07-21-2009 8:43 PM |
Got the blog post out: http://jeffhandley.com/archive/2009/07/21/domaindatasource-dataview.aspx
07-21-2009 9:34 PM |
@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
07-21-2009 10:40 PM |
mrdave: @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.
07-22-2009 2:48 PM |
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.
July CTP DomainDataSource.DomainContext.Entity.Add no longer updates DomainDataSource.Data