This article discusses the most important factors to consider when evaluating .NET datagrids.
.NET datagrids are frequently used to display and edit large data sets with a huge number of records. Raw performance refers to the speed of loading data and posting updates to and from the data source. Many times, datagrids that seem to have more "features" will be slow because of the underlying data architecture needed to support those features. On the other hand, other datagrids are fast and simple to use for developers, but they don't focus as much on end user interactions. A datagrid must strike the right balance between ease of use and performance characteristics that match already established business requirements.
.NET Datagrids that handle virtual data have improved perceived responsiveness due to the ability to transparently load data incrementally, and on-demand, depending on what the end user is doing at the moment. Datagrids should also scroll quickly within the user interface so that the end user continues to have a responsive user experience. The virtual data feature is most useful when an end user is scrolling down the tabular view of a large set of data. This is similar to swiping a touchscreen downwards to force an on-demand refresh on a mobile device.
End users will need to think about whether their preferred way of customizing a .NET datagrid is via the design-time support with wizard-style interface (such as grid designers and property dialogs). The upside is that users don't need to write code to get started. The downside is that these datagrids will generally be much harder to personalize at run time because they will most likely not have a very extensible programming interface. On the other hand, other datagrids may feature a much more extensive programming interface that's granular and allows pretty much anything at run time, even custom drawing the cells. The downside of these datagrids is that they may not come with much wizard-style support, and that means you may have to write code to get started. Be sure to think about run-time flexibility and design-time capabilities when considering a .NET datagrid.
A datagrid that can behave somewhat like a spreadsheet can be useful. For example, end users are already used to performing data analysis and computations inside a spreadsheet, and they will most likely export the data from the grid into Excel for offline use anyway. It makes sense to provide them a user experience that is somewhat compatible when they are using the application. Be sure to find out if a spreadsheet-style user interface is important for business users and, if so, choose a datagrid that allows organizations to meet this requirement within the application in question.
Of course, the .NET datagrid needs to show and manage some kind of data. What may be unique is how to get to the data in the first place. The most common scenario involves connecting to a live data source with known data elements, types and size. All .NET datagrids will typically support this scenario well in some form. The other scenario involves connecting the grid to unbound data - data that will be fetched on-demand dynamically during run time, and is not available or known to begin with. The datagrid needs to be able to correctly present and manipulate the data on screen even though the data itself, the data type and the size and scale of the data, are known only at run time. This is where some grids are just better than the others because their programming interface is more extensible and easier to use. The best way to evaluate a .NET datagrid is to develop a test application that will give end users a good feel for the kind of programming experience they can expect when dealing with unbound data.