Who actually uses DataGrid/GridView/FormView/etc in production apps?

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

Anyone that thinks nobody uses *Grid controls has clearly never worked on an internal corporate webapp.

Answer 2

I'm pretty much writing my own HTML - I'm using the ListView and Masterpages, but not really using the controls much anymore. My ListView laughs at your silly old repeater, by the way.

However, bloatware isn't necessarily a bad thing. If I needed a low volume intranet application built, I'd much rather pay a less experienced developer to drag and drop controls than for an HTML twiddler (like you or me) to craft each tag. There's definitely a place for the quick, simple approach. What's the cost of "bloatware" in that scenario, as long as the control based code is written in a maintainable fashion? Often wiring controls together requires less custom code, which means simple maintenance.

The one place I have to disagree with you - pretty much regardless of the application - is in crafting your own paging queries. You may like to do that kind of thing, but there's absolutely no business value in it. There are several professional-grade DAL tools which will usually write more maintainable, faster queries than most developers. Even if you lovingly craft the perfect paging query, it won't keep up to date with changes to the schema unless you continue to throw hours after it. I think better use of those hours is to build a lightweight system and put those hours into monitoring and fixing specific bottlenecks, rather than immediately jumping to the "database assembly language" layer.

Answer 3

I've been reading your posts guys and it made me feel dumb.

I mean in every application I made where I work there is at least one datagrid/gridview in it. And I didn't have the feeling I am missing something.

Sure I find datagrid/gridview kinda bloated but are they that much disgusting to use?

Answer 4

I think you need to learn to use GridViews before you condemn them. I use them extensively. At first it was a bit challenging to figure out certain things, but now they are indispensible.

GridViews within UpdatePanel with AJAX CRUD and pagination are lightning fast. One of the larger systems set up this way (for internal/external application) has a moderately sized db in the backend. There are many nvarchar(2000) fields and the transitions and updates are great.

In any event, if you've written your own version of displaying data, you may want to continue using it if it works. (Same argument could be made for writing your own compiler, writing your own version of HTML, writing your own version of data access binaries...) The advantage of using GridView is that there are a lot of people who are familiar with it and that MSFT has abstracted/modeled the class to do a lot of things that we used to have to do manually.