Hi Paez,
The reason why my teacher insists that a WS cannot return a Dataset is due
to low rate networks, not due to SOAP schemas. I think that's because a
XML
Dataset is too large.
The size of the SOAP envelope is irrelevant, AFAIK.
It's the schema that makes DataSets seems so large when serialized as xml.
For very small DataSets (in schema and size), the schema might appear to be
half of the entire xml content or more; however, the schema size is a
constant, so as the DataSet scales the schema won't change. If you're
serializing thousands of records, the size of the schema won't make any
difference at all. The size of the actual DataSet content is comparable to
that of a custom collection containing instances of a custom class.
In a Typed DataSet, there is more meta-data per row when it's serialized
than in an untyped DataSet or a custom class. I think this is where that
"DataSets are too big to be serialized as xml" axiom comes in to play.
If you can get away without using a Typed DataSet (which makes sense in a
public Web Service that may be consumed by many different platforms other
than just .NET) then I think you'll find that the amount of data produced
after serialization between an untyped DataSet and a custom class is
comparable.
So, in my WS, I want to turn my dataset in some type of class, and then
send
the client an array of this class elements. Even so, I don't know if this
is
a good idea. What if this class has hundreds or thousands of elements?
Isn't
that too large also? I looking for a way to send the data in small
portions,
but I don't know how... :(
The data has to get there one way or another, so sending them in smaller
pieces isn't going to reduce the overall amount of data that needs to be
sent. Actually, when speaking of xml serialization and SOAP, it will
probably end up being larger than if you were to just make a single method
to send all of the data at once, using a simple class architecture or
untyped DataSet.
--
Dave Sexton