How data driven applications are built generally

Question

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 approxly. 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/colection change,etc. I am unaware of real time app building. Would be nice if I get guidance with this.

Answer 1

These may possibly help:

http://stackoverflow.com/questions/320089/how-do-i-bind-a-wpf-datagrid-to-a-variable-number-of-columns

http://www.codeproject.com/KB/WPF/MovingTowardWpfBinding.aspx

Answer 2

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.

Answer 3

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 :-)

Answer 4

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.