iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
Hi,
Have been using the UxGrid along with WCF Ria using the samples provided by you.
Looks great and works fine too !.
You have suggested that Batch Updates are not available while using WCF RIA.
Why this restriction ?
In what way would the UxGrid be more advantageous than the DCV provided in RIA SP1 where we are able to use the batch update.
Balachander
Hello Balachander,
Bacth Update is not available while using WCF RIA because WCF RIA doesn't support what we called Client-side caching. Therefore, it will retrieve all data from the server-side and overide all changes in the UXGrid.
Client-side caching is needed when we perform Batch Update. Since it is not supported in WCF RIA SP1, then we couldn't use the behavior of Batch Update process. However, DevForce does support client-side caching and that is why we can implement Batch Update when using DevForce.
Hope this helps. Thank you.
Regards,-Martin-
Hi Martin,Thanks for the update.My understanding on WCF RIA is that entities retrieved through a query ARE CACHED on the client side. http://blogs.msdn.com/b/digital_ruminations/archive/2011/01/05/ria-services-output-caching.aspxhttp://www.softinsight.com/downloads/DevConnections/Noyes_SLC_LDA302_DeepDiveIntoRIAServices.pdfSo why this restriction ?How is the use of QueryDescriptor comparable to the DCV introduced in RIA Sp1 ?Balachander Hello Balachander,Bacth Update is not available while using WCF RIA because WCF RIA doesn't support what we called Client-side caching. Therefore, it will retrieve all data from the server-side and overide all changes in the UXGrid.Client-side caching is needed when we perform Batch Update. Since it is not supported in WCF RIA SP1, then we couldn't use the behavior of Batch Update process. However, DevForce does support client-side caching and that is why we can implement Batch Update when using DevForce.Hope this helps. Thank you. Regards,-Martin-
Hi Martin,
Thanks for the update.
My understanding on WCF RIA is that entities retrieved through a query ARE CACHED on the client side.
http://blogs.msdn.com/b/digital_ruminations/archive/2011/01/05/ria-services-output-caching.aspx
http://www.softinsight.com/downloads/DevConnections/Noyes_SLC_LDA302_DeepDiveIntoRIAServices.pdf
So why this restriction ?
How is the use of QueryDescriptor comparable to the DCV introduced in RIA Sp1 ?
For your question, I will need to discuss further with the developer team.
I will let you know when they have provided the information that you need.
Thank you.
Hi Jimmy,Thank you so much for educating me on the differences between Output Caching and Client Side Caching on Devforce. I also understand that on Devforce you have parameters which would optionally force requerying of the data from the server. (QueryStrategy)However, please refer to the link on WCF RIA I had referrred earlier (shown below)http://www.softinsight.com/downloads/DevConnections/Noyes_SLC_LDA302_DeepDiveIntoRIAServices.pdfOn page 6 in the slide titled Update Operations he has mentioned that the Domain Context contains an Entity Container. Entities retrieved through a query are cached client side.Would be very thankful if you help clarify my doubts that Client Side Caching is NOT SUPPORTED in WCF RIA.Thanks once again for the response. RegardsBalachanderDear Balachander,Output caching is entirely different with client-side caching. Output caching is a feature in ASP.NET that allows a specific page to return the cached data based on the cache parameters.The client-side caching in DevForce allows complete persistence in the client-side level (this means at Silverlight client). This also means that data that is already retrieved will not be fecthed anymore from server.For batch update to work, the data service provider is required to have client-side caching capability. Unfortunately, WCF RIA Services doesn't support it.Let me know if you have any questions.Hth,Jimmy
Hi Jimmy,
Thank you so much for educating me on the differences between Output Caching and Client Side Caching on Devforce.
I also understand that on Devforce you have parameters which would optionally force requerying of the data from the server. (QueryStrategy)
However, please refer to the link on WCF RIA I had referrred earlier (shown below)
On page 6 in the slide titled Update Operations he has mentioned that the Domain Context contains an Entity Container. Entities retrieved through a query are cached client side.
Would be very thankful if you help clarify my doubts that Client Side Caching is NOT SUPPORTED in WCF RIA.
Thanks once again for the response.
Regards
Dear Balachander,Output caching is entirely different with client-side caching. Output caching is a feature in ASP.NET that allows a specific page to return the cached data based on the cache parameters.The client-side caching in DevForce allows complete persistence in the client-side level (this means at Silverlight client). This also means that data that is already retrieved will not be fecthed anymore from server.For batch update to work, the data service provider is required to have client-side caching capability. Unfortunately, WCF RIA Services doesn't support it.Let me know if you have any questions.Hth,Jimmy
Hi Jimmy,Thank you very much for the succinct reply.It has helped clarify all my questions and also explained the behaviour I had with WCF Ria.Thank a lot.RegardsBalachander Hi Balachander,Thanks for pointing out about the WCF RIA article.WCF RIA includes a very limited support for client-side caching, which we don't consider it as a full-featured client-side caching. Its implementation is very simple where the retrieved entities will be cached only in query-level session. This means that if you loaded the first page and have some changes, then go to the next page, the previous changes will be gone because they aren't persisted.That kind of caching, for me, is not called client-side caching. It's just saving the retrieved entities temporarily for a single session operation which is not useful in advanced scenarios (because it invalidates the use of editing and changes tracking).Contrary, DevForce implements client-side caching which means the changes you made on previous entities will not lose when you perform another server operation. This enables the batch update feature to be implemented, because it allows you to make changes on first page, jump to next page, do some more changes, and finally click the save button to submit all changes that you've made across the pages.WCF RIA is good and maybe sufficient for basic and simple scenarios such as per-row editing. Our data controls fully support WCF RIA as well, so the choice between WCF RIA and DevForce lies in your scenarios and business requirements. If you're implementing mission-critical apps, I would suggest DevForce because you get first-class products and support. I recalled my poor experience submitting feedback and bug fixes to WCF RIA team and never get responded in years -- I think we cannot expect too much on a free software, can we?Hth,Jimmy
Thank you very much for the succinct reply.
It has helped clarify all my questions and also explained the behaviour I had with WCF Ria.
Thank a lot.
Hi Balachander,Thanks for pointing out about the WCF RIA article.WCF RIA includes a very limited support for client-side caching, which we don't consider it as a full-featured client-side caching. Its implementation is very simple where the retrieved entities will be cached only in query-level session. This means that if you loaded the first page and have some changes, then go to the next page, the previous changes will be gone because they aren't persisted.That kind of caching, for me, is not called client-side caching. It's just saving the retrieved entities temporarily for a single session operation which is not useful in advanced scenarios (because it invalidates the use of editing and changes tracking).Contrary, DevForce implements client-side caching which means the changes you made on previous entities will not lose when you perform another server operation. This enables the batch update feature to be implemented, because it allows you to make changes on first page, jump to next page, do some more changes, and finally click the save button to submit all changes that you've made across the pages.WCF RIA is good and maybe sufficient for basic and simple scenarios such as per-row editing. Our data controls fully support WCF RIA as well, so the choice between WCF RIA and DevForce lies in your scenarios and business requirements. If you're implementing mission-critical apps, I would suggest DevForce because you get first-class products and support. I recalled my poor experience submitting feedback and bug fixes to WCF RIA team and never get responded in years -- I think we cannot expect too much on a free software, can we?Hth,Jimmy
This has been a very educational thread. Thank you all for this info. We've been trying to decide on WFC Ria or Devforce and it appears that Devforce is the way to go. Client side caching is super important for a large SL LOB application we plan to start dev on. Thanks again!
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname