Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Where to store web custom control data

I am creating a custom control extending WebControl. This web control allows the consumer to define a collection of columns in markup, something like this:

<Custom:CustomGrid>
<Columns>
    <Custom:DataColumn HeaderText="FirstName" />
    <Custom:DataColumn HeaderText="LastName" />
</Columns>

and put an IEnumerable in a DataSource property and this is rendered out to a table. This control also allows paging. The IEnumerable in DataSource is the full list, and I display a page of the list at a time. I am already saving the current page, number of rows per page, etc. to viewstate. Should I also put the full list in viewstate? Maybe session? This list can become a bit hefty. Maybe save in session with a random key, which is saved in viewstate? What is the best practice here?

Edit: I don't think it's right to impose that all types in the IEnumerable be serializable. Is that fair? So do I need to copy the data source to some other data structure for serialization?

Edit 2: Even if I do use a base control instead of implementing RenderChildControls I will need to implement CreateChildControls, but I will still need to persist the data somewhere, or did I miss the point of the base class?

like image 871
Elad Lachmi Avatar asked May 01 '26 23:05

Elad Lachmi


1 Answers

Indeed, not all IEnumerable instances will be serializable.

If the query is cheap to run I wouldn't persist the whole data set but just run the query again for a different page or a change in the sort order.

If you put the data in viewstate you'll end up with huge pages. Session state might be acceptable if you don't have many users, but large data sets with lots of users won't scale well. What if I bind a million rows to your control? Or what if your control was used in a repeater and shown 100 times on a page?

Are you sure you need to persist the data? This isn't premature optimisation is it?

Remember that your control is a UI component. The viewstate should hold enough information to maintain the UI state as it is. A change in state (e.g.: switching to a different page of results) is something for which your control should pass responsibility to the data source.

Take a look at good old GridView. It displays what you give it and remembers that. If you're using paging then it raises an event to say "the user has changed page; give me page x of data". For me, that's the best practice for a UI control.

like image 57
batwad Avatar answered May 04 '26 13:05

batwad