In many environments, databinding is something that developers try when knocking out quick demos, while avoiding it for real applications. Some of the concerns include compatibility issues between controls and data sources, loss of control, and additional complexity caused by the very thing that is intended to reduce complexity. If a developer gets caught out by a databound control changing data behind her back, she will likely be put off using it at all.

I've worked with .NET databinding and find it excellent. It is both more flexible and more transparent than what I was used to in Visual Basic or Delphi, and saves a lot of time in both Windows Forms and ASP.NET applications.

Ha! DataBinding is still a bit too "magic" for me. It's not well documented exactly what happens when, and there are some really nasty issues in terms of exceptions being raised when updating the DataSet.

Maybe it's worse in the Compact Framework than in the desktop framework, but it's cost us many man days trying to work round bugs and bits of poor design.

I'm glad someone mentioned this, because it draws attention to the fact that a large proportion of .NET development is going to be focussed on commercial database systems. The client-server model is still very important, and anything which makes the programming of the more mundane but time-consuming aspects of these quicker is going to win a lot of converts.

I'm an expert developer in Borland C++ Builder. The databinding that Borland has within their environment is far better that this stuff that Microsoft has created.

Badly documented, you can't "visually" complete the databinding (must write code), too many components needed to get the data flowing.

I also HATE the fact that it forces ALL of the data to come down to the clientside, I wish this was optional.

And please explain the purpose of the DataTable within the DataSet?
This just adds a level of complexity that is not needed and it makes it very difficult to deal with multi-join SQL statements.

Reggie,

We may be talking about slightly different things. What I like about .NET databinding is that I've found it transparent to work with. Two-way sync between an in-memory data object and a control or controls, and nothing get saved back to the database except when under programmatic control.

The role of the DataSet and DataTable is a different discussion, in that you don't have to use these in order to use databinding. In fact, I often don't. I like binding to collections of my own business objects.

However, I like these classes too. I think of the DataSet as a local DBMS; Borland actually has a similar thing. Hence it contains multiple tables. However, you absolutely do not need to bring all the data down to the client. It's true that there are no server-side cursors, but you don't need to grab more data than you want to display. Ultimately it's all SQL queries. The ability to save as XML and preserve a record of changes is handy for offline apps.

I agree that the DataSet is rather complex if you make use of all its features (constraints etc) but these often aren't needed. I also agree that the data wizards in VS.NET 2003 are poor - but that's a tools issue. I know it's been worked on extensively in VS.NET 2005.

Tim

Tim,

I now understand what you are talking about, and yes, I was on a different, but, similiar subject.

I truly hope that the DataSet components have been worked on in VS.NET 2005

One point I'd like to pick up on: server-side cursors. It's perfectly possible to write a client server app without using a single server side cursor: I've written several. You just code the business logic in stored procedures. Server-side cursors tend to be indicative of poor architectural design: people writing cleint-server apps as if they were still powered by Jet.



--------------------------------------------------------------------------------------------
deadlyvices@hotmail.com
Currently writing the GuideDog editor using MSHTML in my copious free time...

I have done a lot of databinding in winforms. I found out it works well under normal simple binding. It fails to bind properly when binding to complex business objects.

I have a business object (a class) that has a list of product categories and each category has a list of products.

Now in a standard window application, to show the categories and products, you would have a form with 2 tabs - one for category and one for its products.

But, if you bind the datagrid in the first tab to the category list, and bind the datagrid in second tab product list, the product list won't refresh properly according to the selection of categories in the first tab. You have to rebind the second tab whenever it is activated (opened).

What I mean is datagrid1 is binded to BusObj.CategoryList and datagrid2 is binded to BusObj.CategoryList.ProductList.

Q.How do you implement one-to-one, one-to-many and many-to-many relationships while designing tables?

One-to-One relationship can be implemented as a single table and rarely as two tables with primary and foreign key relationships.
One-to-Many relationships are implemented by splitting the data into two tables with primary key and foreign key relationships.
Many-to-Many relationships are implemented using a junction table with the keys from both the tables forming the composite primary key of the junction table.

It will be a good idea to read up a database designing fundamentals text book.