Data Bound Controls - Is It Safe Yet?

[resoremix]

Has anybody got any input on the potential implications of using data bound controls in vb.net for a production application.

It's well known that they were to be avoided for anything other than prototyping in VB6 but given that the ADO.NET model is now based around disconnected datasets surely the main problem of poorly managed connections is no longer a consideration.

I'm looking for the absolute fastest performance from my application. I used to achieve this in VB6 through a firehose cursor and populating my controls through code. I know that a similar route is still possible using a datareader but I'm keen to go with the recommended disconnected route for client/server apps.

Surely binding controls to an ADO.NET datatable has no down sides. After all, you're only binding to an in-memory database.

Someone please tell me if I'm wrong and why before I start to venture into previously avoided coding.

Thanks a lot

 

[WyldRose]

I databind to a subclassed combobox and out of box datagrid in many production Winforms. I haven't noticed any performance problems with these when bound to a dataset, datatable, or datarow. You just have to get use to the idea of disconnected datasets that .NET pushes. In reality, it seems Microsoft did their homework and made a really good framework for all of this.

The biggest performance hit comes from filling your dataset(s) and datatable(s). You just want to group several database hits into one transaction and you'll have no problems.

 

[chiph]

I've heard that the databinding in .NET is actually pretty fast. You probably still have the connection count problem to manage (bound controls on a form want their own connection, consuming database licenses), but that can probably get gotten around.

One cool thing I've heard of being done (but haven't tried it yet myself) is writing your own data adapter that maps your own data (like from an XML string) to a format that bound controls could read.

Chip H.