Hi,

We are in the process of designing an ASP.NET app, where a user will
enter some 'Customer ID' to be queried in the database. If the ID is
valid, several stored procedures will be called to populate multiple
webpages containing customer information. There isn't a one-to-one
correlation between the stored procedure and a webpage. In other
words, a webpage may have to refer to 1 or more DataTables to populate
itself. Therefore, a DataTable that was used to populate webpage1 will
need to be kept to populate webpage2.

In order to make this process quick and efficient, we are trying to
devise an effective scheme. Here are a couple of options we've come up
with. I would highly appreciate it, if you folks can give your
comments and/or suggestions on this matter.


Option 1: Object Model.
Create a CustomerInfo Object with the necessary properties, and
populate it (using a DataReader)with the values returned by calling
each of the stored procedure, store the object in a session variable,
and use it to populate the webpages.


Option 2:
Store each of the DataTables returned from the stored procedures in
DataSet, save the DataSet in a session variable, and use it to
populate each of the webpages.


So, my question are...

Is it worth creating a Customer object (option1) to populate the
various pages, or is it just better to use a DataSet (option2),
despite the fact it will be larger in size? BTW, we are estimating the
size of the Customer object to be ~8-10K. How much extra overhead will
a DataSet add?


Also, we will be hosting the app on a webfarm, so the session
variables will be saved on SQL server. And the information is needed
only once to populate the pages. There will approximately be 8
webpages showing customer info, and 7 stored procedures to be called.

Again, I thank you for you help, and I look forward to your response.

In your solutions I donot like

a) The suggestion of dataset holding your object, datasets are frickin'
huge, and hopefully you aren't going to viewstate them
b) Holding client state info on the server.

If it were me designing the app, I would do the following ...

Set a session expiring cookie at the client that stores the Customer ID.
Typically this cookie would be set in page #1, and read from page #2-end.
Since this is common behavior, implement a base page that does this, and all
your other pages should inherit from this base page.

In each page (therefore in the base class), you should have an object
representation for the customer. This representation must embellished in
each derived page for the page specific information (hence a property ..
depends on your exact design). The base class asks for the cookie, if it
exists, based upon that recreate the remote browser's world .. this might be
counter intuitive and less performing, but this is more scaleable, not to
mention you are sending much lesser stuff over the pipe, and your app is in
general more scaleable.

Once your custom object is created and populated, you can then bind it to
various controls on your asp.net webpage. This binding should actually be
done on a usercontrol for better code manageability. If the pages depend on
a sequence i.e page #3 needs to remember page #2 needs to remember page #3,
then viewstate the object. If the object is too huge, then override
ViewState behavior so that either it gets compressed, or alternatively donot
send it to the client, instead store it in your session mgmt sql server -
which now can just be a table in your regular sql server or a brand new sql
server.

What are the advantages of this approach?

a) Your being able to totally control how much data goes to the client.
b) Your being able to add/remove servers from a webfarm without any apparent
effect to the client
c) No client affinity on the webservers, so they don't even have to be
homogenous.

Then again, your requirement might not merit the extra effort. You would be
a better judge of that. :-)

Just my 2 cents.

- Sahil Malik
You can reach me thru my blog -
http://www.dotnetjunkies.com/weblog/sahilmalik



"Yul" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> We are in the process of designing an ASP.NET app, where a user will
> enter some 'Customer ID' to be queried in the database. If the ID is
> valid, several stored procedures will be called to populate multiple
> webpages containing customer information. There isn't a one-to-one
> correlation between the stored procedure and a webpage. In other
> words, a webpage may have to refer to 1 or more DataTables to populate
> itself. Therefore, a DataTable that was used to populate webpage1 will
> need to be kept to populate webpage2.
>
> In order to make this process quick and efficient, we are trying to
> devise an effective scheme. Here are a couple of options we've come up
> with. I would highly appreciate it, if you folks can give your
> comments and/or suggestions on this matter.
>
>
> Option 1: Object Model.
> Create a CustomerInfo Object with the necessary properties, and
> populate it (using a DataReader)with the values returned by calling
> each of the stored procedure, store the object in a session variable,
> and use it to populate the webpages.
>
>
> Option 2:
> Store each of the DataTables returned from the stored procedures in
> DataSet, save the DataSet in a session variable, and use it to
> populate each of the webpages.
>
>
> So, my question are...
>
> Is it worth creating a Customer object (option1) to populate the
> various pages, or is it just better to use a DataSet (option2),
> despite the fact it will be larger in size? BTW, we are estimating the
> size of the Customer object to be ~8-10K. How much extra overhead will
> a DataSet add?
>
>
> Also, we will be hosting the app on a webfarm, so the session
> variables will be saved on SQL server. And the information is needed
> only once to populate the pages. There will approximately be 8
> webpages showing customer info, and 7 stored procedures to be called.
>
> Again, I thank you for you help, and I look forward to your response.

<<datasets are frickin huge>>
Your statement is in complete agreement with almost everything I have read
about datasets - however in a different group I saw a discussion in which an
MVP claimed that datasets are huge only when persisted (at least he stated
that datasets are not stored as verbose xml unless they are persisted to
disk) - and when in memory, they do not require more overhead than other
structures. This was all in the context of discussing which in-memory
structures should be used to maintain data that can be represented as rows
and columns - and datatables/datasets was one option amongst arrays, hash
tables within hash tables, custom classes etc.

Is any clarification available on this? - as no conclusive support was
provided one way or the other...

Thanks.



"Sahil Malik" <(E-Mail Removed)> wrote in message
news:u%(E-Mail Removed)...
> In your solutions I donot like
>
> a) The suggestion of dataset holding your object, datasets are frickin'
> huge, and hopefully you aren't going to viewstate them
> b) Holding client state info on the server.
>
> If it were me designing the app, I would do the following ...
>
> Set a session expiring cookie at the client that stores the Customer ID.
> Typically this cookie would be set in page #1, and read from page #2-end.
> Since this is common behavior, implement a base page that does this, and
all
> your other pages should inherit from this base page.
>
> In each page (therefore in the base class), you should have an object
> representation for the customer. This representation must embellished in
> each derived page for the page specific information (hence a property ..
> depends on your exact design). The base class asks for the cookie, if it
> exists, based upon that recreate the remote browser's world .. this might
be
> counter intuitive and less performing, but this is more scaleable, not to
> mention you are sending much lesser stuff over the pipe, and your app is
in
> general more scaleable.
>
> Once your custom object is created and populated, you can then bind it to
> various controls on your asp.net webpage. This binding should actually be
> done on a usercontrol for better code manageability. If the pages depend
on
> a sequence i.e page #3 needs to remember page #2 needs to remember page
#3,
> then viewstate the object. If the object is too huge, then override
> ViewState behavior so that either it gets compressed, or alternatively
donot
> send it to the client, instead store it in your session mgmt sql server -
> which now can just be a table in your regular sql server or a brand new
sql
> server.
>
> What are the advantages of this approach?
>
> a) Your being able to totally control how much data goes to the client.
> b) Your being able to add/remove servers from a webfarm without any
apparent
> effect to the client
> c) No client affinity on the webservers, so they don't even have to be
> homogenous.
>
> Then again, your requirement might not merit the extra effort. You would
be
> a better judge of that. :-)
>
> Just my 2 cents.
>
> - Sahil Malik
> You can reach me thru my blog -
> http://www.dotnetjunkies.com/weblog/sahilmalik
>
>
>
> "Yul" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hi,
> >
> > We are in the process of designing an ASP.NET app, where a user will
> > enter some 'Customer ID' to be queried in the database. If the ID is
> > valid, several stored procedures will be called to populate multiple
> > webpages containing customer information. There isn't a one-to-one
> > correlation between the stored procedure and a webpage. In other
> > words, a webpage may have to refer to 1 or more DataTables to populate
> > itself. Therefore, a DataTable that was used to populate webpage1 will
> > need to be kept to populate webpage2.
> >
> > In order to make this process quick and efficient, we are trying to
> > devise an effective scheme. Here are a couple of options we've come up
> > with. I would highly appreciate it, if you folks can give your
> > comments and/or suggestions on this matter.
> >
> >
> > Option 1: Object Model.
> > Create a CustomerInfo Object with the necessary properties, and
> > populate it (using a DataReader)with the values returned by calling
> > each of the stored procedure, store the object in a session variable,
> > and use it to populate the webpages.
> >
> >
> > Option 2:
> > Store each of the DataTables returned from the stored procedures in
> > DataSet, save the DataSet in a session variable, and use it to
> > populate each of the webpages.
> >
> >
> > So, my question are...
> >
> > Is it worth creating a Customer object (option1) to populate the
> > various pages, or is it just better to use a DataSet (option2),
> > despite the fact it will be larger in size? BTW, we are estimating the
> > size of the Customer object to be ~8-10K. How much extra overhead will
> > a DataSet add?
> >
> >
> > Also, we will be hosting the app on a webfarm, so the session
> > variables will be saved on SQL server. And the information is needed
> > only once to populate the pages. There will approximately be 8
> > webpages showing customer info, and 7 stored procedures to be called.
> >
> > Again, I thank you for you help, and I look forward to your response.
>
>

I believe the MVP is correct (Who was it?). When persisted, or serialized,
datasets in framework 1.1 use XmlSerializer and you cannot override that
behavior easily. ADO.NET 2.0 will have DataSet.RemotingFormat to get around
this problem.

So in memory, they would probably be represented as any other object and not
as xml. This "any other object"'s size depends on it's complexity, the
number of properties it might have etc. which might lead to a larger vtable
in memory. Dataset, even considering that is pretty huge a structure.

Hard to say if there is an online material which compares various
datastructures when serialized, but you could write a small sample and check
it out for yourself. Generally writing your own representation of a business
object that internally usees Hashtable or Arraylists etc. is a good
solution. If you throw a dataset as one of the objects contained within the
hashtable, you would get a bloated serliazed form again, since wherever a
dataset is encountered, you would see xmlSerializer come back in effect.

- Sahil Malik
You can reach me thru my blog -
http://www.dotnetjunkies.com/weblog/sahilmalik



"Guadala Harry" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> <<datasets are frickin huge>>
> Your statement is in complete agreement with almost everything I have read
> about datasets - however in a different group I saw a discussion in which
> an
> MVP claimed that datasets are huge only when persisted (at least he stated
> that datasets are not stored as verbose xml unless they are persisted to
> disk) - and when in memory, they do not require more overhead than other
> structures. This was all in the context of discussing which in-memory
> structures should be used to maintain data that can be represented as rows
> and columns - and datatables/datasets was one option amongst arrays, hash
> tables within hash tables, custom classes etc.
>
> Is any clarification available on this? - as no conclusive support was
> provided one way or the other...
>
> Thanks.
>
>
>
> "Sahil Malik" <(E-Mail Removed)> wrote in message
> news:u%(E-Mail Removed)...
>> In your solutions I donot like
>>
>> a) The suggestion of dataset holding your object, datasets are frickin'
>> huge, and hopefully you aren't going to viewstate them
>> b) Holding client state info on the server.
>>
>> If it were me designing the app, I would do the following ...
>>
>> Set a session expiring cookie at the client that stores the Customer ID.
>> Typically this cookie would be set in page #1, and read from page #2-end.
>> Since this is common behavior, implement a base page that does this, and
> all
>> your other pages should inherit from this base page.
>>
>> In each page (therefore in the base class), you should have an object
>> representation for the customer. This representation must embellished in
>> each derived page for the page specific information (hence a property ..
>> depends on your exact design). The base class asks for the cookie, if it
>> exists, based upon that recreate the remote browser's world .. this might
> be
>> counter intuitive and less performing, but this is more scaleable, not to
>> mention you are sending much lesser stuff over the pipe, and your app is
> in
>> general more scaleable.
>>
>> Once your custom object is created and populated, you can then bind it to
>> various controls on your asp.net webpage. This binding should actually be
>> done on a usercontrol for better code manageability. If the pages depend
> on
>> a sequence i.e page #3 needs to remember page #2 needs to remember page
> #3,
>> then viewstate the object. If the object is too huge, then override
>> ViewState behavior so that either it gets compressed, or alternatively
> donot
>> send it to the client, instead store it in your session mgmt sql server -
>> which now can just be a table in your regular sql server or a brand new
> sql
>> server.
>>
>> What are the advantages of this approach?
>>
>> a) Your being able to totally control how much data goes to the client.
>> b) Your being able to add/remove servers from a webfarm without any
> apparent
>> effect to the client
>> c) No client affinity on the webservers, so they don't even have to be
>> homogenous.
>>
>> Then again, your requirement might not merit the extra effort. You would
> be
>> a better judge of that. :-)
>>
>> Just my 2 cents.
>>
>> - Sahil Malik
>> You can reach me thru my blog -
>> http://www.dotnetjunkies.com/weblog/sahilmalik
>>
>>
>>
>> "Yul" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> > Hi,
>> >
>> > We are in the process of designing an ASP.NET app, where a user will
>> > enter some 'Customer ID' to be queried in the database. If the ID is
>> > valid, several stored procedures will be called to populate multiple
>> > webpages containing customer information. There isn't a one-to-one
>> > correlation between the stored procedure and a webpage. In other
>> > words, a webpage may have to refer to 1 or more DataTables to populate
>> > itself. Therefore, a DataTable that was used to populate webpage1 will
>> > need to be kept to populate webpage2.
>> >
>> > In order to make this process quick and efficient, we are trying to
>> > devise an effective scheme. Here are a couple of options we've come up
>> > with. I would highly appreciate it, if you folks can give your
>> > comments and/or suggestions on this matter.
>> >
>> >
>> > Option 1: Object Model.
>> > Create a CustomerInfo Object with the necessary properties, and
>> > populate it (using a DataReader)with the values returned by calling
>> > each of the stored procedure, store the object in a session variable,
>> > and use it to populate the webpages.
>> >
>> >
>> > Option 2:
>> > Store each of the DataTables returned from the stored procedures in
>> > DataSet, save the DataSet in a session variable, and use it to
>> > populate each of the webpages.
>> >
>> >
>> > So, my question are...
>> >
>> > Is it worth creating a Customer object (option1) to populate the
>> > various pages, or is it just better to use a DataSet (option2),
>> > despite the fact it will be larger in size? BTW, we are estimating the
>> > size of the Customer object to be ~8-10K. How much extra overhead will
>> > a DataSet add?
>> >
>> >
>> > Also, we will be hosting the app on a webfarm, so the session
>> > variables will be saved on SQL server. And the information is needed
>> > only once to populate the pages. There will approximately be 8
>> > webpages showing customer info, and 7 stored procedures to be called.
>> >
>> > Again, I thank you for you help, and I look forward to your response.
>>
>>
>
>