views:

63

answers:

1
A: 

It (based in part on the earlier question) sounds like bandwidth is the issue; I would give serious thought to trying protobuf-net; the "protocol buffers" format designed by Google is very efficient (much more so that the default DataContractSerializer), and it can be used very conveniently from .NET. Ideal for bandwidth-related scenarios. The only glitch is that currently the WCF hooks don't work with Silverlight (so you can't just add an attribute / config entry), but you can pass the data as a byte[] easily enough (just return byte[] from a method).

For example; if you have a record like:

[ProtoContract]
public class MyRecord {
    [ProtoMember(1)]
    public int Id {get;set;}

    [ProtoMember(2)]
    public string Description {get;set;}

    // etc
}

and a List<MyRecord>, then you should be able to use:

byte[] result;
using(MemoryStream ms = new MemoryStream()) {
    Serializer.Serialize(ms, list); // or maybe (list, ms) ;-p
    result = ms.ToArray();
}

I've also seen somebody return a Stream on the operation-contract (rather than a byte[]) - which seemed to work better with MTOM (hint: you definitely want to enable MTOM if possible when passing raw binary).

Marc Gravell
The issue would come on the silverlight side. Right now I don't believe there is a simple way of retrieving the serialized info. The BinarySerializer isn't part of the silverlight framework.
Buddy Lee
Also from the looks of it, the transport latency isn't too bad. The app will run close to the db. Trick would be finding a way to get all the data in one swoop, rather than having to go back 4 times, which is causing my 8 second delay.
Buddy Lee
Which is why I didn't mention `BinaryFormatter`; I mentioned an alternative (and more efficient) binary serializer that *does* work in both regular and Silverlight; http://code.google.com/p/protobuf-net/
Marc Gravell
4 calls is trivial if latency is low; it sounds more like bandwidth to me...?
Marc Gravell