tags:

views:

215

answers:

1

I have a list (ListView) which which displays a lot of information, and what I want to do is get the DataItem after its DataBounded, ie on the ItemCommand event.

I know I can just store the keys in the DataKey, but I need to store a lot more info than keys.

The information comes from various external sources and I only need to save the ones the user has clicked on.

A few solutions

  1. Store the key and re-obtain it from the external datasource, but this is expensive and slow
  2. Store the data in the session, expensive in memory
  3. Store in all incoming data in db, but again, the data is not needed
  4. Store in viewstate, this would create a massive view state...
  5. Get the data from the view itself, but I dont display all the data I need, some information is not displayed, ie Id's

As I write this I believe there is no real solution apart from what I have written above.

Anyone have better solutions?

A: 

You could use a non-visible literal controls in your list view template to store your extra data. You could put anything in there like xml if you have complex objects. This would leverage viewstate though for each row so you would have the same issue as your #4 except you would have it stored at the row level in a control which is saving it's context to the viewstate instead of manually managing the data in the viewstate yourself.

I wouldn't recommend #5 because relying on the view's data will cause you to have to revalidate that data server side to make sure someone hasn't messed with it.

At some point you need to store the information server side or client side. If you are worried about server side storage or the retreival process being slow as a problem then store it client side but realize this will increase your bandwidth and client side and request processing.

You really need to test your specific case to see where you can afford to put the load as there is no magic that will eliminate this load.

Kelsey
Thanks for your ideas Kelsey. It really does come to storing it server side, client side, or neither, all have their pros and cons. Client side issues is there is a lot of data, and really would overwhelm the client. Server side would be the better solution. My final decision is to store the incoming data in a temporary database which will have a job to clean up and reference the ID's in the DataKey, and then copy the relevant information as needed.
Jason Jong