Shared DomainContext beetween QueryableDomainServiceCollectionView

[Vasile]

Hello,

I have the following problem:
I do an MVVM silverlight application consuming data from a RIA web service (OpenAccessDomainService)
I have two views created in a PRISM region, one is active the other is hidden I can toogle between them.
Both views will use view models exposing a Products collection declared as QueryableDomainServiceCollectionView<Product>
ViewA will bind the Products collection to a RadDataGrid - here I can add, edit or remove Products
ViewB will bind the Products into a combo box allowing one product selection as a property of another type of entity.

My goal is to operate changes in both views and then submit all changes at once on the server.

I had the following approach...
I was thinking to use a single (shared - singleton) DomainContext on the constructor call of the two ODSC<Product> memebers in the two view models, to be able to gather changes in all views in a single submitable DomainContext. This seems to work however the ODSC<Product> instances seems not to sync with the shared DomainContext. I mean if I add new products in the ViewA (using RadDataGrid) then those changes will be propagated in the DomainContext, however the ODSC in ViewB's view model will not be aware about the new products.

Is there a way to resync the ODSC only with the data available in the local DomainContext? without reloading from the server? Even if I will reload from server it will not work because the added products are still pending submision to the server.
This could be somehow addressed by using a shared ODSC<Product>, but this will only solve only this simple case I encountered, there are more complex situations with different filters on views bound to different controls so using shared ODSC will not work always, I need a way to refresh somehow the ODSC instances when changes occurs in data context.

I appreciate any ideea, or references to architetcure & design "papers" exlaining how this type of requirement can be designed.
Vasile

[Rossen Hristov]

Hello Vasile,

According to your specific needs you have several options:

If you want to share the entities you have to have a single instance of the QueryableDomainServiceCollection view.

Now you can have this single QDSCV that communicates with the server and you can have two other views of type QueryableCollectionView that will have the QDSCV as their source collection. You can create these two different QueryableCollectionView instances by passing the single QueryableDomainServiceCollectionView instance to their constructors. You can use these two different QCV's for your PRISM need.

Finally, you have a third option and that would be to subscribe to the relevant DomainContext events and synchronize your two QDSCV<T>'s in case you decide to stick with this architecture.

I hope this helps.

Kind regards,
Ross
the Telerik team

[Vasile]

Hello Ross,

At first sight the solution with two (or many) QueryableCollectionView looks very nice, I will have to check if that really does the job. The third option would be a nightmare. I am gonna check the solution (two QCV) in the evening and confirm if it does the trick. My only concern is that QDSCV does something in plus to QCV to support the UI controls.

Thanks
Vasile

[Rossen Hristov]

Hi Vasile,

Actually, QueryableDomainServiceCollectionView derives from QueryableCollectionView. In fact, it is a QueryableCollectionView capable of talking to a DomainContext and pulling data from the server.

The interface that other controls care about is called IQueryableCollectionView and as long as their Source/ItemsSource implements this interface they don't care about the specific implementor.

In other words, a control like RadGridView will not care whether you feed him with a QCV or a QDSCV. The only thing it cares about is whether its ItemsSource implements the IQueryableCollectionView interface. This is the interface that is responsible for syncing all Sort- and FilterDescriptors (and several other things as well).

So you can try to create two QCV's and then feed them with the single instance of the QDSCV (in their constructors). This should keep the three collections in sync. I hope this helps.

Kind regards,
Ross
the Telerik team

[Vasile]

Hello Ross,

I confirm now that the solution with two QCV sharing the same QDSCV will produce expected behavior.

Thank you,
Vasile