Best way to populate webpages from multiple tables

  • Thread starter Thread starter Yul
  • Start date Start date
Y

Yul

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
 
<<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.
 
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
 
Back
Top