DEVHIDE
Login Or Sign up

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

7.9k Views Asked by At

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... ­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

asp.net data-controls
Original Q&A
26

There are 26 best solutions below

0
On

Components like the GridView/FormView/DataGrid follow the 80/20 rule.

This means that 80% of the time when you use them for simple purposes they get the job done and are extremely easy to implement.

But 20% of the time you will be trying to build something complex (or weird) and you will be forced to jump through a dozen hoops and bend the code in many ways to try to implement a solution.

The trick is to learn whether the problem is an 80 problem or 20 problem, if you can identify the 20 problem early you are much better off writing the code from scratch yourself and ditching the "time saving" one.

0
On

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.

0
On

I'm trying to look at it all in context. I have a page that has a nice gridview (displays 10 rows at a time, 6 columns, sorting, and paging) and if I just look at the html table that is created along with the viewstate, I'm only seeing 29k of code.

Is 29k vs. 18k for using a repeater or listview really worth all the effort in these broadband times?

I personally stick with the gridviews however the design guy I work with sometimes gripes about trying to style it via css.

0
On

I use them extensively in the corporate environment I work in and I'm working with one right now. The people who don't use them remind me of all those "I built it with Notepad" developers of years past. What's the point of using asp.net if you're not going to take advantage of the time savings?

0
On

Just reading your posts. I agree PHP is easier than asp. but I just started using visual studio for formviews and gridviews. Can not get much easier for either vb or C# programmers. ASP still has problems uploading large files. PHP it's a snap. I run PHP under IIS 7.5

0
On

I never really used the standard WinForms grid before but at my last job we used the ComponentOne FlexGrid extensively and it worked beautifully. There were still some annoyances with trying to get all the customization we wanted but overall it saved us a ton of time and produced beautiful results.

Currently I'm working with Silverlight 3 and RIA Services and I can't imagine trying to produce what we're doing without the DataGrid and DataForm controls. The time being saved far outweighs any of the overhead.

0
On

I have never used it. I completely agree, it's bloatware. I usually end up using the repeater with custom controls that i made.

0
On

For anything long term I would try to avoid datagrid/gridview, it sometimes becomes too hacky making it do exactly what you want, after a certain number of these tweaks you start to realise its not saving time in the long run and you might not be getting the control over markup that you need.

However the built in paging and sorting functionality works well and in 2008 there is a new ListView control which aims to sort some of these problems out and give you tighter control of the html that is output.

0
On

I really like the telerik radgrid. Their product ain't cheap, but you get a lot of controls and features. And the data binding support is pretty good, both in a simple asp.net data source binding way and in a more custom handle-your-own-databinding-events kind of way.

0
On

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.

1
On

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>
0
On

At my company we use grids everywhere, mostly ComponentArt Grid (http://www.componentart.com/). Yeah it's bloatware but you get a lot of functionality that wouldn't be much fun to re-invent: sorting, paging, grouping, column reordering, inline editing, templating (server-side and client-side). The client-side APIs are nice too.

1
On

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?

2
On

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

0
On

I like the GridView control and have used it in several custom DotNetNuke modules for my company's web site. For one thing, using the built-in controls means less dependencies to worry about. And once I had it set up how I wanted it, I basically copied the code to other pages and just had to do minor tweaks.

I've found that there are so many options with modern grid controls (Infragistics, Telerik, etc) that it takes longer to configure the grid than anything else. The MS controls are pretty simple yet they can do pretty much anything.

0
On

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.

0
On

Every single app we development at my company has grids (the apps are all behind the firewall). That includes both web apps and Winform apps. For the web apps it's the good ole gridview with custom sorting for the winform apps we use Janus grid. I'm trying to get the developers/users to think of a better user interfaces but it's a tough to change. I gotta admit its still better than the alternative of the users building their "own" apps with Access that I would then need to support!

0
On

Using controls like the GridView are great for simple apps. Even if you are a server-side HTML bracket-twiddling ninja, they can make developing simple stuff much less time consuming. The problem is that they usually start to expose their shortcomings eventually, and you end up having to spend time tweaking them anyway. But at least you can get up and going quickly to start out with.

For example, the default paging in a GridView doesn't support paging in the database itself (you have to load all the rows before it will page them), so once you start feeling that pinch in performance, you may need to think about rolling your own or, perhaps better, find a more capable grid control.

Anyway, the point is that pre-built components are good. They help. But as usual, it depends on what you need them to do.

0
On

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.

0
On

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.

0
On

If you work with designers a lot on public facing web sites then you should ditch the GridViews and stick to repeaters. That's my opinion anyway - I've had to pull apart hundreds of GridViews and turn them into simple repeaters in order to fulfill the design requirements.

If you go near DataGrids or GridViews with a 10-foot pole on a public facing web site then you HAVE to use the CSS friendly Control Adapters. (At this point you might find it easier just to do it in the Repeater.) Prior to Control Adapters being available I would have considered these controls broken out of the box.

I find that too many .NET developers do not have a good understanding of design, accessibility, CSS, javascript, standards etc. which is why they succumb to GridViews, ObjectDataSources etc.

0
On

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.

0
On

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.

0
On

We use the Infragistics UltraWebGrid + LinqDataSource on our intranet apps.

It gives us ajax, sorting, filtering, paging all server side.

The "export to excel" also is a killer feature.

We have 5000+ users,lots of data, performance is excelent.

0
On

i am a moderate level developer i can say without these controls i couldn,t ever learn developing.just you have to admit yourself to it for a while till you find your way to customize it and the end result will be great

0
On

I largely abandoned grids once I started designing from user stories, rather than from database table requirements. And never editable grids. The old way was just how we coerced users into doing data entry/table maintenance for our systems, and it never matched their workflow - any real job ended up skipping from one master/child form to another.

And the users never figured it out - but they sure knew our applications were harder to use than they should be.

An exception is analytical applications. But there are relatively few of those, and they are largely read-only.

Related Questions in ASP.NET

Related Questions in DATA-CONTROLS

Trending Questions

Popular # Hahtags

javascript python java c# php android html jquery c++ css ios sql mysql r reactjs node.js arrays c asp.net json python-3.x ruby-on-rails .net sql-server swift django angular objective-c pandas excel

Popular Questions

Copyright © 2021 Jogjafile Inc.