Take the 2-minute tour ×

I am a newbie .net programmer learning WPF for past one month. One thing I am confused from the start is how real time data driven applications are built. I started with a basic application where I required to bind data to a datagrid which would have some 10 columns approx. The common way of data binding I have seen in all the tutorials is they have a sample data with which they build a business object(two/three fields at the max). But when it comes to handling larger data objects do they write getter/setters for all of the 10/15 fields? For that I preferred binding DataGrid to DataTables directly which involved less code. But it seems this approach might miss several advantages like getting notified on source/collection change,etc. I am unaware of real time app building. Would be nice if I get guidance with this.

share|improve this question
On a side note, once you get past about 7 columns, the data becomes increasingly difficult to comprehend for a typical person. If you have a lot of data to present, it's highly recommended that you have some way of filtering which columns to display. Depending on the nature of the data, it may also be possible to aggregate some of the columns together to provide meaningful summary information that's easier to comprehend than the raw columns. For these types of questions, it's helpful to collect use cases for how users will actually want to use the data and shape the UI to match. –  Dan Bryant Sep 21 '10 at 13:15
add comment

4 Answers

up vote 2 down vote accepted

I don't have experience of more than 15-20 columns in a DataGrid, but for that I did create getters and setters for the properties.

Creating a code snippet which templates a property with INotifyChanged helps of course also. http://drwpf.com/blog/2007/11/17/my-wpf-code-snippets/

It can also depend on where you get your objects from. In one project I did, the entities came from Entity Framework, which did implement INotifyPropertyChanged on properties, so in that case I didn't need to write wrapping properties. I could bind the entities properties directly to datagrid's columns.

share|improve this answer
add comment

These may possibly help:



share|improve this answer
First link is a different scenario and the second one is basics to binding. But I wanted to know how 10's of fieds involving collection objects are built in real apps. –  sarath Sep 21 '10 at 12:24
add comment

There is no silver bullet to developing data-driven apps. I write Enterprise Resource Planning application using a SOA-style application structure for a living - and I can assure you that I never use DataTables directly :-). DataTables are IMO fine if you have only one user and limited amounts of data. As soon as you add the second user... you should move away from DataTables (and DataSets etc.)

But to answer your question - when I have large datasets with objects with many properties, I tend to show at a max around 10 columns - if there are more properties, I put them in a Details section/separate details view. I then bind the individual columns to the 10 (or so) most important properties of the objects.

I only use DataGrid (read-write tabular data) for very small collections with rather simple objects - usually a collection property of the parent object. Everywhere else I use a ListBox or a ListView and only show the data (read-only) - and then a detail-section for creating/updating a single item. This makes it a lot easier handling CRUD (Create/Read/Update/Delete)-actions to and from the database (or whatever datastore you have).

It can be a bit overwhelming to start in WPF with the many possibilities - but I would advice you to look at M-V-VM at some point to really leverage the power (and simplicity) of WPF. I've written a ten-post blog-series for one way of doing it - it starts here. It may be a wee bit above your level if you're just starting out, but save it for one of those days where you cannot fall asleep... :-)

Hope this at least gave you a few pointers :-)

share|improve this answer
Hi Goblin, thanks for that. Really I could choose this as second answer if its permitted. Thanks again for the ideas. :) –  sarath Sep 23 '10 at 7:25
No worries - happy it helped you :) –  Goblin Sep 23 '10 at 7:41
add comment

Generally in large scale enterprise applications you do have Business Objects(BO's) having 8-10 properties(fields). When Tables in DB gets bigger normalization is done to keep the number of columns less and create different tables(connected via foreign keys); same is done in case of Bo's, they are designed(using various OOP's concepts) so that each BO will have all related properties together and of maintainable size. Large BO's will be combination of these smaller BO's. This enhances the Usability and at the same time you don't have to deal with BO's having a lot of properties.

share|improve this answer
add comment

Your Answer


