Hello,
I recently had problems regarding a "not found" exception when calling the rootlist.BeginSave method from the silverlight UI. I have found that the problem is directly linked to the size of the object to save. If I have a collection of 1000 objects, it does not work, but with only 2 objects, it works.
This problem is easily solved by using the binaryXML binding using silverlight only(not using csla light)
With Csla light, on the other hand, it seems that even if the client side and server side are correctly configured to use binaryxml binding, the problem still occurs. I have found that Csla.DataportalClient.WcfProxy had the basicHttpBinding hardcoded into it and I wondered why...
There are many possible solutions to my problem, one is to use compression on my objects, or just send the dirty items to the beginsave method.
So I have 2 questions :
Thank you!
"easily solved" is an overstatement. BinaryXML helps, but is far from a complete solution. The FAQ has quite a bit of information
http://www.lhotka.net/cslanet/faq/DataPortalFaq.ashx
If are you running current code, you are using binary xml, because that's the default for the SL data portal. If you are using older code, well, you should keep current. CSLA .NET for Silverlight was created originally with SL2, which didn't have these options, and CSLA continues to evolve as SL is evolving - which is incredibly fast.
But even with binary xml, you need compression and you need to raise the (really low) default message size limits, at least for anything beyond the simplest demo or POC.
Fortunately the SL data portal is specifically designed to make it easy to plug in compression - see the Silverlight video series or numerous posts on this forum for info.
In 3.8.3 the data portal has been opened up further, so it is possible to create completely new proxy/host pairs, like is possible in .NET. This was meaningless in the early days of SL, but makes sense now due to the increasing number of possible network communication protocols (WCF and other) available. And it is important because it enables the use of third-party WCF channels, among other things.
I just wanted to add that you'd be surprised at how much verbosity there is in the serialized objects - to give you relevant comparison, I had a read-only list of 2000 or so items (larger than I'd personally like) and the thing was around 15MB. After compression, it was 200K, much more "doable".
I'd say the typical compressions I've run into are anywhere from 90%-96% - so definitely explore this route!
Compression is definately the way to go. It solved the problem.
I still wonder why basichttpbinding is hardcoded into wcfportal tough.
Thanks for the prompt answers.
Again, this code was created with SL2 where the only option was basicHttpBinding.
In January of 2009 however, WcfProxy was altered so you could create your own WCF channel factory and/or WCF proxy. So you can use any binding you'd like, basicHtttp is simply the default. If you are still seeing it as hardcoded, you need to upgrade to more current code.
CSLA 3.8.3 removes all restrictions on the bindings by allowing you to create your own proxy/host pair, so you can pretty much do anything you'd like.
Copyright (c) Marimer LLC