0

Is there a significance performance issue with changing Gridview *BoundFields* into TemplateFields with Labels? (please see code excerpts below)

I'm planning to implement the change above due to a lot of requirement changes with the gridview fields, to make the code much more easier to maintain. Less code change is required when fields are just rearranged.

Using BoundFields seems more error prone, since one has to be very careful to keep track of all the occurrence of cell indexes. Especially with Gridviews with a lot of fields that are accessed all over the place.

Any help/advice is appreciated.

Thanks in advance.

LABEL:

On Page:

<asp:TemplateField HeaderText="Field1">
     <ItemTemplate>
         <asp:Label ID="lblField1" runat="server" Text='<%# Eval("Field1")%>' />
     </ItemTemplate>
</asp:TemplateField>

In Code:

Label lblField1 = row.FindControl("lblField1") as Label;
if (lblField1 != null) { string field1 = lblField1.Text; }

BOUNDFIELD:

On Page:

<asp:BoundField DataField="Field1" HeaderText="Field1" />

In Code:

string field1 = row.Cells[2].Text;
niki b
  • 989
  • 3
  • 10
  • 30

1 Answers1

0

use the hastable dataItem instead of cells object

dataitem("Field1"). Then you don't need to worry about cell indexes.

EDIT: So it would appear unless you are rebinding your grid at page load you will not have a dataitem to work with.

That being said I can not substantiate this claim but I would think the template field would be better suited for your needs because thought it is probably more process intensive, you will get a reference to the object for that extra processing.

Basically the bound field resolves to a cell in the table, where as the label will resolve to a span that has a reference. The DOM is going to be different and your access to the data is also different.

So there will be more overhead using the label, but you get easier access.

I would not say there is 'significant' performance issues unless of course you are not paging a couple hundred records. then I would guess that the bound field would be less intensive simply because you are not generating as much html.

Pow-Ian
  • 3,607
  • 1
  • 22
  • 31
  • Can you please post a somewhat working code? I tried using "row.DataItem("Field1") but it says I cannot use it as a method. Also tried "row.DataItem["Field1"].ToString()" and it did not work (getting nulls). Coding "DataRowView rowView = (DataRowView)row.DataItem" then use "rowView["Field1"].ToString()" also did not work (Cannot apply indexing to object). – niki b Nov 20 '12 at 21:31
  • Not sure what is missing. If you have a valid GridView Row then the dataitem should exist. – Pow-Ian Nov 20 '12 at 21:37
  • I'm not sure what I am missing too. The GridViewRow row is a valid object, but the DataItem in it is null, so I cannot implement your solution. Thanks for the tip though. – niki b Nov 20 '12 at 21:43
  • the dataitem might be null if the row is not a data row. Are you sure you are looking at only datarows when you are trying to get the string? – Pow-Ian Nov 20 '12 at 21:44
  • Okay, it seems like the DataItem is only available in RowCreated and RowDataBound events. http://forums.asp.net/t/1539224.aspx/1. And yes, the RowType is DataRow. – niki b Nov 20 '12 at 21:46
  • http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.gridviewrow.dataitem.aspx from that link: Use the DataItem property to access the properties of the underlying data object to which the GridViewRow object is bound. The DataItem property is only available during and after the RowDataBound event of a GridView control. That suggests to me that it can be used. – Pow-Ian Nov 20 '12 at 21:47
  • That's okay. Thanks for the help. I'm using C#. – niki b Nov 20 '12 at 21:50
  • http://stackoverflow.com/questions/7090794/accessing-the-data-or-dataitem-used-to-bind-a-gridview that is why it works for me, I always bind my grids in page load. – Pow-Ian Nov 20 '12 at 21:54
  • unfortunately, binding created a slew of other issues, so using the dataitem might not be the solution in our case. – niki b Nov 20 '12 at 22:06