Draw backs of Serialized Objects

[Ben Kim]

Hello all,

We are diving into VB.NET 2005 head first, coming from a language called
Clarion. What are some of the drawbacks, if any, to serialized objects?
Should we just use streaming data? The environment will be as follows:

Multiple data stores (could be SQL Server databases across LAN, WAN,
internet... could be a mainframe system)
These disparate result sets will be combined into a single return
When returned to the requestor, the results will be displayed in a tree list
view

With that in mind, take a person inquiry. The requestor will be filling out
a "filter" form and sending the request in XQUERY or an XML like language to
a server process which could be located anywhere. The server process would
create separate threaded requests to each data store. Once each data store
has responded (or timed out), the responses are combined and grouped into
like names (IE: Social Security Numbers match and Last Name as an
example). This is serialized into an object or an XML response is created
and returned to the user, in Zipped format most likely. The requestor
unzips or unserializes the response and displays it to the end user for
further action.

In your professional opinion what is going to be the optimal way to package
the request and response given the data could be coming from a local LAN or
across the internet? We are looking for the least load on the servers and
wire/wireless systems and fastest response time.

Any input would be greatly appreciated!

Take care,

Ben Kim
Emergitech

 

[Cor Ligthert [MVP]]

Ben,

You can load datasets in one instructions the sqldataadapter.fill, most can
be done generic as well, than you .

Try to make yourself a complete program
Select in top the Tab Datasource
Select database
Follow the wizard
Select again in top the Tab Datasource
Select that datasource drag it on your form.

Program made to get and update data.

I hope this helps,

Cor

 

[Ben Kim]

Cor,

How would I create a single data source from multiple sources that may not
even be "databases"? For example, we have a state and federal system that
we send up XML queries and are returned XML result which we parse and add to
the final result set. Could I create a dataset (the final result) and
store all related returns into the data set?

Thanks!

Ben Kim

 

[Cor Ligthert [MVP]]

How would I create a single data source from multiple sources that may not

even be "databases"? For example, we have a state and federal system that
we send up XML queries and are returned XML result which we parse and add
to the final result set. Could I create a dataset (the final result) and
store all related returns into the data set?

Yes withouth any problem, however you cannot add something from a dataset,
what has no tables in the database of course.

Dim ds as news dataset
dim dt as new datatable
ds.tables.add(dt)
dt.column.add("state")
dt.column.add("federalSystem")

It is not important if the dataset, datatable exist already, however it does
not fill of course automaticly the values it does not know,

(Although that filling can even be done by using an expression).

I hope this helps,

Cor

 

[CMM]

A dataset doesn't have to be tied to any one database. All it really is is a
collection of array of arrays on steriods. You can create a dataset and load
it manually with data from any datasource. So, the answer to your last
sentence is: YES.

Having said that, datasets- when serialized- contain overhead (even when
serialized using the new VS2005 binary serialization options for datasets)
that doesn't apply to other "simpler" lists or arrays. It doesn't get
simpler or more efficient than serializing an array of strings if bandwidth
is of the utmost importance.

Or, if your're "zipping" up the data, you can serialize the data (either a
dataset or an array of objects) to a file, zip it up, and send the file as a
a byte array.... also a very efficient mechanism.

 

[CMM]

To further Cor's example:
You construct the dataset either in code (using exactly Cor's sample)
*or*
You can construct a "Typed Dataset" using the designer (Project -> Add New
Item -> Dataset... just make sure to skip any database source wizards that
might come up and design the dataset yourself). The dataset that you design
basically becomes a strongly typed *class* in your project with real
fields... like a normal class (instead of o.Item("FirstName"), which is
prone to errors, it becomes o.FirstName).

Regular dataset
Dim ds as New Dataset
' .... all your construction code here
' .... could be a lot of code!
ds.Tables(0).Row(whatever).Item("Telephone") = "555-5555"

vs.
Typed dataset
Dim ds As New MyAwesomeDataset
ds.MainTable.Row(whatever).Telephone = "555-5555"

I even use Typed datasets (or rather a Typed DataRow) as singular entity
objects. Who cares? In that case the Row is the "entity" and I can pass it
around as such. You can create, maintain, and refer to a Datarow all by
itself without the Dataset. Instant Entity Object!... with souped up null
handling and typing checking features to boot!