Data-Bound Vs. Non-Data-Bound Controls 
Author Message
 Data-Bound Vs. Non-Data-Bound Controls

We've got a technical debate on our development team about using data-bound
controls.

The back-end is SQL7 and we're using VB6 and ADO to connect to it.  One
group insists that data-bound controls are terrible.  They want to do
everything by hand (i.e. code an ADO connection, generate a recordset, step
through each field for the current record, and then do manual assignments
i.e. field1.text = recordset.field(1).value).  The other group thinks this
is tedious and a waste of valuable time (we've got a tight deadline).
They're fine with coding a connection & generating a recordset, but feel it
would be wiser to bind the fields to the recordset and have that binding
take care of populating the the fields with data.

Some of the arguements I heard against this include a significant increase
in the number of open connections (i.e. 1 connection per data-bound
control), buggy implementations of the controls, & slower performance than
hand-coding.

I've searched MSDN On-Line for several hours and it appears that they think
ADO and data-bound controls are ok to use in any application.  Nothing I've
read states that in some many words, however, the tone of the articles imply
it.  We've got a tight deadline and need to resolve this ASAP.  Does anyone
know of any articles that examine this issue in detail or has anyone had any
experience with this issue?  I'm looking for a neutral 3rd party
source/expert that can help me put this issue to rest so we can get on with
the development effort.

Thanks in advance.

Gerry Baldwin
Universal Data Solutions



Sat, 10 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
I can't give you a reference to any articles, but I can give you my
experience.

You mentioned some of the most significant reasons NOT to use databinding.
All are very valid, but only a real issue if they impact your specific
project.  Do you have more then 20 users that will be hitting your SQL
Server?  How many data controls will you need to have instantiated at any
one time?  Mutlipy the number of users * the number of data controls, you
have the number of static connections to the server.  If it is small enough,
then no big deal.

I've never really had any issues with controls getting 'buggy' because of
data binding.  I'm not saying it couldn't happen, just that it is not one of
the issues that would stop me from using data binding, as it must be an
infrequent issue.

Slower performance is again an issue of user connections.  If you have few
enough connections, then no big deal.

Now let me offer some additional negatives to data binding.

1. granularity of developer control.
    When you data bind, you give up a lot of flexibility and elegance in
your code.  There are some things you simply will not be able to do, and
others that you will have to create some ugly hack arounds to accomplish.
This alone is a big enough reason to shy away from data binding.  Major
factor.
2. Size of distributable file
    When you decide to use data binding, you are also deciding to use data
bindable controls.  This means more then just the standard vb controls, no
longer is it reasonable to use a combo box, you need to us the Data List
Controls, other controls have similiar situations.  This means that you will
need to include more .ocx files in you projects, hence a larger
distributable set.  Not a major factor, but one to consider.
3. Maintainance of code.
    Data binding also pretty solidly keeps you from creating a component
based solution.  You are going back to the large, client side applications
that must be updated as a whole instead of a solution that incorporates COM
components which are more easily upgraded and repaired during the life time
of the app.  The trade-off here is fast initial development and longer
redevelopment down the road.  Since we all know that every application sees
a degree of change during it's life-time this is a major factor
4. Pride
    'nough said I think. :)

If you are under a time constraint, I say weigh the pros and cons and do
what you must.

Kirk Graves
MCSD, MCT


Quote:
> We've got a technical debate on our development team about using
data-bound
> controls.

> The back-end is SQL7 and we're using VB6 and ADO to connect to it.  One
> group insists that data-bound controls are terrible.  They want to do
> everything by hand (i.e. code an ADO connection, generate a recordset,
step
> through each field for the current record, and then do manual assignments
> i.e. field1.text = recordset.field(1).value).  The other group thinks this
> is tedious and a waste of valuable time (we've got a tight deadline).
> They're fine with coding a connection & generating a recordset, but feel
it
> would be wiser to bind the fields to the recordset and have that binding
> take care of populating the the fields with data.

> Some of the arguements I heard against this include a significant increase
> in the number of open connections (i.e. 1 connection per data-bound
> control), buggy implementations of the controls, & slower performance than
> hand-coding.

> I've searched MSDN On-Line for several hours and it appears that they
think
> ADO and data-bound controls are ok to use in any application.  Nothing
I've
> read states that in some many words, however, the tone of the articles
imply
> it.  We've got a tight deadline and need to resolve this ASAP.  Does
anyone
> know of any articles that examine this issue in detail or has anyone had
any
> experience with this issue?  I'm looking for a neutral 3rd party
> source/expert that can help me put this issue to rest so we can get on
with
> the development effort.

> Thanks in advance.

> Gerry Baldwin
> Universal Data Solutions




Sat, 10 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
I agree with pretty much all of the comments to date.

One point worth mentioning though is the flexibility of the user interface.
I've worked with clients who really did want a very fast implementation and
didn't care much about the look and feel of the GUI. In this case it all
works well - for a while ;-)
The REAL bad thing about bound controls (IMHO) is where the client asks for
a particular kind of GUI (or even a 'simple' change to an existing one) that
the bound controls you're using are not geared up for.

Generally, I've found the bound controls approach gives a very fast startup
but almost always leads to problems later on. In almost every case, the
client asks for something that is not intuitive with the set of grids and
boxes you've got. In the end I always seem to be working around the controls
rather than with them.

Maybe if your client is REALLY willing to sacrifice GUI flexibility for a
fast delivery, they're the right choice.


Quote:
> I can't give you a reference to any articles, but I can give you my
> experience.

> You mentioned some of the most significant reasons NOT to use databinding.
> All are very valid, but only a real issue if they impact your specific
> project.  Do you have more then 20 users that will be hitting your SQL
> Server?  How many data controls will you need to have instantiated at any
> one time?  Mutlipy the number of users * the number of data controls, you
> have the number of static connections to the server.  If it is small
enough,
> then no big deal.

> I've never really had any issues with controls getting 'buggy' because of
> data binding.  I'm not saying it couldn't happen, just that it is not one
of
> the issues that would stop me from using data binding, as it must be an
> infrequent issue.

> Slower performance is again an issue of user connections.  If you have few
> enough connections, then no big deal.

> Now let me offer some additional negatives to data binding.

> 1. granularity of developer control.
>     When you data bind, you give up a lot of flexibility and elegance in
> your code.  There are some things you simply will not be able to do, and
> others that you will have to create some ugly hack arounds to accomplish.
> This alone is a big enough reason to shy away from data binding.  Major
> factor.
> 2. Size of distributable file
>     When you decide to use data binding, you are also deciding to use data
> bindable controls.  This means more then just the standard vb controls, no
> longer is it reasonable to use a combo box, you need to us the Data List
> Controls, other controls have similiar situations.  This means that you
will
> need to include more .ocx files in you projects, hence a larger
> distributable set.  Not a major factor, but one to consider.
> 3. Maintainance of code.
>     Data binding also pretty solidly keeps you from creating a component
> based solution.  You are going back to the large, client side applications
> that must be updated as a whole instead of a solution that incorporates
COM
> components which are more easily upgraded and repaired during the life
time
> of the app.  The trade-off here is fast initial development and longer
> redevelopment down the road.  Since we all know that every application
sees
> a degree of change during it's life-time this is a major factor
> 4. Pride
>     'nough said I think. :)

> If you are under a time constraint, I say weigh the pros and cons and do
> what you must.

> Kirk Graves
> MCSD, MCT



> > We've got a technical debate on our development team about using
> data-bound
> > controls.

> > The back-end is SQL7 and we're using VB6 and ADO to connect to it.  One
> > group insists that data-bound controls are terrible.  They want to do
> > everything by hand (i.e. code an ADO connection, generate a recordset,
> step
> > through each field for the current record, and then do manual
assignments
> > i.e. field1.text = recordset.field(1).value).  The other group thinks
this
> > is tedious and a waste of valuable time (we've got a tight deadline).
> > They're fine with coding a connection & generating a recordset, but feel
> it
> > would be wiser to bind the fields to the recordset and have that binding
> > take care of populating the the fields with data.

> > Some of the arguements I heard against this include a significant
increase
> > in the number of open connections (i.e. 1 connection per data-bound
> > control), buggy implementations of the controls, & slower performance
than
> > hand-coding.

> > I've searched MSDN On-Line for several hours and it appears that they
> think
> > ADO and data-bound controls are ok to use in any application.  Nothing
> I've
> > read states that in some many words, however, the tone of the articles
> imply
> > it.  We've got a tight deadline and need to resolve this ASAP.  Does
> anyone
> > know of any articles that examine this issue in detail or has anyone had
> any
> > experience with this issue?  I'm looking for a neutral 3rd party
> > source/expert that can help me put this issue to rest so we can get on
> with
> > the development effort.

> > Thanks in advance.

> > Gerry Baldwin
> > Universal Data Solutions




Mon, 19 Aug 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Data-Bound Vs. Non-Data-Bound Controls

2. Data-Bound Vs. Non-Data-Bound Controls

3. Data-bound Masked Edit makes all data-bound controls not display data

4. Data Environment vs Data Bound Controls

5. Bound vs Un-Bound data

6. Data Bound Combo Box within a Data Bound Grid

7. Data bound Combos or Not Data Bound Combos

8. Creating a *NON* Data-Bound Form with *NON* Data Bound Controls... HELP!!!!

9. How to create a data bound control that binds to a row

10. Data Bound User Control Not Binding

11. binding a data bound grid control programmatically

12. ?Data bound controls lost binding after filtering

 

 
Powered by phpBB® Forum Software