简体   繁体   中英

Populating Gridview

I'm currently working on asp.net webforms project and i have a page with

  • asp:textbox
  • asp:DropDownList
  • asp:linkbutton

I also have an asp:gridview on the same page, and i need to insert a new row on it whenever i clicked a linkbutton without saving the data into a DataBase . The way i used to achieve that is to save the data on a ViewState list.

So, my question is: Isn't there a better way to do that ? if yes , please show it in details.

Update: I must not lose the gridview data when PostBack happens.

You are looking for ASP .NET State Management and there are several ways of dealing with it:

  • View state
  • Control state
  • Hidden fields
  • Cookies
  • Query strings
  • Application state
  • Session state
  • Profile Properties

Since you didnt provide more information i would suggest you to use Session state to save the data since it's the easiest way of doing it because the information is going to be stored on the server side where it belongs (Instead of wrongly using ViewState where the information is going twice to the client, one in de GridView.DataBind() and one more in the ViewState). You need to do something like this:

MyGridView.Datasource = (List<Object>)Session["myGridViewData"];
MyGridView.DataBind();    

Whenever you insert/delete/modify a new row you must update the dataset in your myGridViewData Session variable.

And remember to refresh GridView.DataSource on every postback so you dont loose the information:

protected void Page_Load(object sender, EventArgs e)
{
  grid1.DataSource = getDataSet();
  grid1.DataBind();      
}

private List<Object> getDataSet()
{
    if (Session["myGridViewData"] == null)
        Session["myGridViewData"] = new List<employee>();            

    return (List<Object>)Session["myGridViewData"];
}

protected void addNewRowButton_Click(object sender, EventArgs e)
{
    List<Object> list = (List<Object>)Session["myGridViewData"];       
    list.Add(new Object ());
    Session["myGridViewData"] = list;
}

Keep in mind that is not a good practice to update controls on Page_Load event, you should instead handle which of your postbacks refreshes the data and refresh the grid on the apropiate methods (page first loads, and add/modify/delete row).

If you are using .NET Framework 4.5 or superior i will advise you to use GridView model binding (SelectMethod) GridView Model Binding With this is not necesary to refresh the DataSource on every postback explicitly in the Page_Load method which is a cleaner way of doing this.

EDIT: From here

Session State or ViewState?

There are certain cases where holding a state value in ViewState is not the best option. The most commonly used alternative is Session state, which is generally better suited for:

  • Large amounts of data. Since ViewState increases the size of both the page sent to the browser (the HTML payload) and the size of form posted back, it's a poor choice for storing large amounts of data.

  • Secure data that is not already displayed in the UI. While the ViewState data is encoded and may optionally be encrypted, your data is most secure if it is never sent to the client. So, Session state is a more secure option. (Storing the data in the database is even more secure due to the additional database credentials. You can add SSL for even better link security.) But if you've displayed the private data in the UI, presumably you're already comfortable with the security of the link itself. In this case, it is no less secure to put the same value into ViewState as well.

  • Objects not readily serialized into ViewState, for example, DataSet. The ViewState serializer is optimized for a small set of common object types, listed below. Other types that are serializable may be persisted in ViewState, but are slower and generate a very large ViewState footprint.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM