Who actually uses DataGrid/GridView/FormView/etc i

Question

Curious if others feel the same as me. To me, controls such as datagrid/gridview/formview/etc. are great for presentations or demo's only. To take the time and tweak this controls, override their default behavior (hooking into their silly events etc.) is a big headache. The only control that I use is the repeater, since it offers me the most flexibility over the others.

In short, they are pretty much bloatware.

I'd rather weave my own html/css, use my own custom paging queries.

Again, if you need to throw up a quick page these controls are great (especially if you are trying to woo people into the ease of .NET development).

I must be in the minority, otherwise MS wouldn't dedicated so much development time on these types of controls... ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

Answer 1

I too would like to see an expanded answer on why GridView et al are considered "bloatware." I have extensively used GridView as well as 3rd party products (Telerik, etc) and find that for the majority of internal and some external projects, they work great. They are fast, easy to use, customizable - and BEST - I can hand them over to someone who knows GridViews who can then easily pick up where I left off. If I were to hand-code all of the numerous apps/controls, the overhead in the next person figuring out what is going on would be enormous even under the best of circumstances.

For me, I can see some of the 3rd party products being bloatware (but still sometimes useful), but the bare-bones GridView I've found to be quite fast with moderate queries.

Answer 2

They are one of the benefits of asp.net. Up until just recently I hated them, but the more you use them the easier they become, once you learn what setting you must change for which instances. Mainly I like the form view and listview the gridview still needs some work.

Answer 3

I have wondered about this for a long time. There seems to be a consensus here that the grid controls are bloatware. But, can anyone definitively cite the cost of using these controls? Is there excessive HTML sent to the browser? Too much resource devoured on the server? Is generating the HTML table faster (assuming it's well-written)?

In addition to the bloatware issue, I have often run aground when UI requirements are enhanced to include features beyond the scope of the standard controls. For example, in early ASP.Net versions, I struggled with putting images in column headers. And, I believe it's still a challenge to add a second, top-level header row spanning multiple columns. At some point, it becomes really difficult to wrestle with the control to achieve the desired effect. And it's frustrating if you know the HTML you want, but you just can't make the control do it.

On one project, I finally gave up and wrote myself an HTML table class to generate a very complicated grid. It took a couple of days to get it just right. But, now I have the basic code, and it will be much more efficient to tweak that for future grids.

No doubt about it, though. It's hard to beat the fancy grid controls for speedy development, if you can just live within their limitations.

Answer 4

GridView is fine and very powerful control and works well with css or theme. The only thing that is annoying me is that VirtualCount property was dropped when old 1.1 DataGrid was replaced with GridView in asp.net 2.0 and it was useful for implementing custom paging. However same can be done via data adapters.
Though working with repeaters is maybe clearer and you have total control over rendered html still I wouldn't recommend going on that ways because is harder to implement and maintain.

Answer 5

I've actually used GridView extensively for an adminsitrative console. I even created a custom DataFieldControl that sets the field's header text and sort expression based on data field, creates an Insert row in the bottom and automatically collects the values in the row and forwards them to the data source's insert method, and generates a list box if an additional list data source is specified. It's been really useful though a huge time investment to build.

I also have another control that will generate a new data form based on the fields' metadata when there are no records (in the EmptyDataTemplate).

<asp:GridView ...>
 <Columns>
       <my:AutoField HeaderText="Type" 
                      DataField="TypeId"
                      ListDataSourceID="TypesDataSource"
                      ListDataTextField="TypeName" />          
  </Columns>

    <EmptyDataTemplate>
        <my:AutoEmptyData runat="server" />
    </EmptyDataTemplate>

</asp:GridView>

Answer 6

For my corporate intranet projects, grids are indispensable. They are the foundation for easy reporting on the ASP.NET webforms platform.

Easy to Design Paste the grid on the page. Insert BoundField objects for simple binding. asp:HyperlinkField for easy linking.

Binding

You can bind grids in a handful of ways:

• a collection of objects (List, ArrayList, Hashtable, or any simple collection)
• SqlDataReader in your code-behind (yikes, that would require SQL in your presentation tier)
• SqlDataSource (specify a stored proc. All the columns on the resultset map directly to the grid's columns. It's a very quick and dirty if the report doesn't mimic your domain object nicely. i.e. summations of different things.)
• objectDataSource (binding to a method on your BL)

For those who might call out SqlDataSource and ObjectDataSource, you don't always have to have them declared in your .aspx.cs or .aspx.vb . I am not advocating them here, just pointing out the possibilities.

I don't think you can discount the RAD benefits of the built-in GridView and other 3rd party grids. Management types love and want tabular data.