Bound or Unbound? That is the question.

[SpicyMikey]

I'm a long time vb programmer and am moving our vb6 apps to vs2005 (finally). It has always been considered "bad practice" to use bound controls, especially on larger applications with a clear two or three tier architecture. All our front ends call backend routines that return datasets or arrays which are then loaded into grids, etc. Changes are then recorded and loaded back to the database via backend routines. Fully unbound processing.

Question is this; does anything change in .NET? Are there any compelling reasons to reconsider that strategy? I'm new to .NET and trying to get a feel for "best practices".

Thanks

[Hack]

Welcome to the forums.

I am an old VB6 programmer who shares the disdain for bound controls. In fact, I think they are evil.

Having said that, I've been told, and have read numerous articles which indicate that the way bound controls work in .NET is a tremendous improvement over the way they worked in VB6. According to those in the know, they are far more flexibile and can be of great benefit.

Actually, I would not know about this from first hand experience because I still have an innate dislike and distrust of bound controls. I don't, and won't, use them.

I'm rewriting some VB6 apps in .NET, and the .NET versions will be as unbound as the VB6 versions are.

[SpicyMikey]

Thanks for the warm welcome Hack.

I'm with you regarding bound controls. Something just feels wrong about the idea still. Considering the fact that all the code is already in place for unbound loading, I suppose I'll leave it that way unless someone has a fantastic reason I should change it.

On a related note; any experience with grids and which are the best to use? I've looked at the standard grid and it looks as useless as the vb6 version. We use True DBGRid and are considering upgrading to the .NET version. Anyone have any opinions on that? It seems to support unbound use still, although it works differently. Some coding rework necessary

[stanav]

Suppose you have a datatable filled with data from your query and a datagrid. In VB6, how would you go about displaying the data in the grid unboundly?

[techgnome]

Like HAck, I'm an old school-bound-controls-are-evil... and not just evil... but eeeeeeeeeeevil. In VB6....

With .NET, I've changed my opinions SOME... I still have an adversion to binding controls directly to datatables and datasources, UNLESS they are lookup items of lists, like a list box, or a combo box. There, I bind to load the data then toss the datatable.

What I have no qualms about binding controls to though are my data classes. The day I found out that I can bind my controls to the classes themselves, rather than some dataset/table was a banner day. No more writing endless code of shuffling data out of the object, into the control, then shuttling it it back into the object so it can be saved.

It also means that the object can do the validation, and isn't relying on the screen to do that... and now the object has direct control over it's dirty setting. It's much cleaner, and reliable than previous version of databinding in VB.

But I will not ever, bind directly to the dataset/table.

Hack - I'd suggest looking into it.... I realize I'm probably just spitting into the wind here, but just give it a try... once.... before you write it off completely. I've never liked bound controls either, and you know I hate them just as much as you (no one could hate them more) but binding to an object is a phenomenal step forward. I was amazed at just how easy it was and how well it worked.

-tg

[techgnome]

Suppose you have a datatable filled with data from your query and a datagrid. In VB6, how would you go about displaying the data in the grid unboundly?

That's a bit different... the data binding in VB6 that caused so much grief for a lot of people was the ADODC... the DataSource control that you could just drop on to a form, set the conneciton, then set the DataSource of all controls to the ADODC, then set the field to what ever field.... things are great... until you hit your first NULL value... or forget to save something, it led to all kinds of problems and confusion. It was a bad concept that went wrong.

-tg

[SpicyMikey]

Like HAck, I'm an old school-bound-controls-are-evil... and not just evil... but eeeeeeeeeeevil. In VB6....

With .NET, I've changed my opinions SOME... I still have an adversion to binding controls directly to datatables and datasources, UNLESS they are lookup items of lists, like a list box, or a combo box. There, I bind to load the data then toss the datatable.

What I have no qualms about binding controls to though are my data classes. The day I found out that I can bind my controls to the classes themselves, rather than some dataset/table was a banner day. No more writing endless code of shuffling data out of the object, into the control, then shuttling it it back into the object so it can be saved.

It also means that the object can do the validation, and isn't relying on the screen to do that... and now the object has direct control over it's dirty setting. It's much cleaner, and reliable than previous version of databinding in VB.

But I will not ever, bind directly to the dataset/table.

Hack - I'd suggest looking into it.... I realize I'm probably just spitting into the wind here, but just give it a try... once.... before you write it off completely. I've never liked bound controls either, and you know I hate them just as much as you (no one could hate them more) but binding to an object is a phenomenal step forward. I was amazed at just how easy it was and how well it worked.

-tg

Hmm, any examples you can point me too? I'm trying to grasp the idea of what that means from an implementation perspective.

[Hack]

Suppose you have a datatable filled with data from your query and a datagrid. In VB6, how would you go about displaying the data in the grid unboundly?

I never used grids as I did not, and do not, like the way they work.

Whenever I need this type of display I always used the ListView.

[Hack]

Hack - I'd suggest looking into it.... I realize I'm probably just spitting into the wind here, but just give it a try... once.... before you write it off completely. I've never liked bound controls either, and you know I hate them just as much as you (no one could hate them more) but binding to an object is a phenomenal step forward. I was amazed at just how easy it was and how well it worked.

Well, Ok....if someone like you recommends at least trying, I suppose I could give it a shot.

However, rest assured it will be in a test project. I'm not letting any bound control within 5 lights years of my production projects.

[SpicyMikey]

I never used grids as I did not, and do not, like the way they work.

Whenever I need this type of display I always used the ListView.

Obviously, grids are good when you need to allow the user to change data, but I agree, it can be overkill for just displaying.

Stanav: if you are suggesting the situation where you have a huge database and you want to give total visibility to the data through a grid (like viewing a table in SQL Enterprise Manager, etc.) then I agree using unbound techniques can be a disaster. But, if you're designing a business application, you are hopefully avoiding the need to do something like that. Normally you are displaying a subset of data (invoices for a customer for the month of April, etc.) In that case the volume is small and is easier handled by both you and the user. The user is displayed the 10-20 records, can make changes, and then you commit those changes back to the database when the user is done.

[Hack]

I recall numerous spec gathering meeting where the user wanted every single record in a specific table displayed, and I always managed to talk them out of it.

Displaying too many record will annoy the bejesus out of most people when they want to find a specific record fairly quickly. I've never encountered an experience where the ListView failed to work for me.

[techgnome]

I dispise grid editing.... open the data in a form, let them edit, save it, roll it back, print it, etc....

-tg

[SpicyMikey]

One size does not fit all. There are situations where grid data entry is useful. Spreadsheet type data entry.

Earlier you mentioned something about bindign to classes. Can I ask how you do that?

[techgnome]

I'll have to get back to you on that.... I don't have any samples handy.

-tg

[SpicyMikey]

No problem. I thought you might have a URL or somethign that talks about the idea. Sounds interesting!

[techgnome]

Try this:

TextBox1.DataBindings.Add("Value", myNewClass, "Prop1")

The first parameter is the name of the property of the CONTROL that you want to bind to... since it's a text box, I bound to the .Value property... but you can also bind the forecolor, back color.... and property... the second parameter is the instance of the class you are binding the control to. The third parameter is the name of the object's property that will be bound to the control's property....
Here's the MSDN entry:
http://msdn2.microsoft.com/en-us/lib...gs(VS.80).aspx

-tg

edit - if I remember later, I'll post a function I wrote that enumerates the controls and binds them based on the values found in it's Tag property.

[SpicyMikey]

very cool. I could see this having potential. I'll check it out. Thanks!

[jmcilhinney]

Without having read the majority of this thread I just wanted to add my two cents. You should always choose data-binding as a first option. Data-binding is not limited to DataSets and DataTables. You can bind lists of business objects in exactly the same way, so there's no limitation there. There will be some situations where data-binding is not suitable, but those will be in a minority. Use it where it suits and then don't where it doesn't, but if you use it as much as you can you'll save yourself a LOT of work and reduce the likelihood of errors in your code while doing so.