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
Using Bound Controls that are bound to a disconnected recordset are not
going to consume connections.

If you were using the datacontrol, then sure, this would be an issue.

In theory, the ability to Bind Controls to an ADO Recordset or a COM
Component is a huge improvement over VB5.

I am not sure that I would use bound controls in an application because I am
just used to coding ADO by hand. BUT,.....I don't think the other engineers
arguments are valid either. It sounds like they are not being open minded to
me.

I Certainly would not use the datacontrol and bind my forms directly to the
database. I would stick tightly to the N-Tier Model

--
Cheers,

Gregory A Jackson MCSD, MCT
Sr Software Engineer
STEP Technology
PDX, OR



Sat, 10 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
I'm in the process of doing some prototyping for a rewrite of our legacy
system, and I'm not using bound controls.  On a previous project I got
burned BAD BAD BAD by (DAO) controls that didn't always behave consistently
in terms of the data binding.

Now I put a "field" property in my Business Objects, and then wrote some
generic subroutines to do things like look at the "data field" property of a
form's control and pass it to the field property of the BO... basically I've
simulated data binding but also get all the benny's of using the n-tier
model.  Once my BO is written, I can whip out a UI JUST AS QUICKLY as if
using full data binding.

Just my $.02.


Quote:

> I Certainly would not use the datacontrol and bind my forms directly to
the
> database. I would stick tightly to the N-Tier Model

> --



Sat, 10 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls

I read Greg's response about using bound controls with disconnected
recordsets, and he is correct. However, only by binding directly to the
database will you get the development speed that the second camp
is hoping to achieve.

The first camp that opposes the use of bound controls has a better
understanding of the potential pit-falls. Either they are more seasoned,
well-read, or simply smarter (Darwin has a point, you know).

Mike

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




Mon, 12 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
Everyone is going to have their own opinion on this one based on their own
experiences, some good some bad.

My experience of trying to use bound controls is that they offer much but
have inconsistent reliability.

Since ditching them our applications have performed consistently better. We
adopt a Business Objects approach and now avoid binding. Coding takes longer
but results offer many advantages. The biggest advantage is that we are
masters of our own destiny and do not have to rely on MS to fix the problems
that we have experienced in the past. Being able to fix your own problems
gives you more project control.

Yes MS do think ADO and Binding are OK but you would expect that given ADO
is their flagship data access technology and VB their langauge of choice for
DB applications. However I would challenge their developers to come and use
it to develop real applications to real business deadlines, without the
backing or knowledge of their in house people, which I do not have easy
access to.

Regards,

Graham


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




Tue, 13 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
I agree completely with Graham. My experience has been that you give up too
much control with databinding, and you certainly don't gain any performance.
If you use datasource controls, you're going to be using way too many
database connections. Also, if you go the n-tier route you really want to
separate database access from the gui anyway.

Of course Microsoft is going to tell you that ADO and databinding work well
together; it's their product, and a big selling point of VB is that the
bound controls, data environment designer, etc, all make database
programming easier. For them to come out and admit that unbound controls are
the way to go for more robust programs would be pretty stupid.

Jeff



Fri, 16 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
Bound controls seem to work well on smaller projects, but they do incur
overhead and I have found that over time they can lead to some serious code
maintenance. They also scale poorly, at least in the implementations I've
done. Perhaps most importantly, the robustness is inconsistent at best.
Controls like the date picker end up either unbound or replaced by lesser
controls anyhow, because they can't handle Nulls. If your interface requires
various control types, you'll want to investigate how those controls will
react to binding against Nulls, or empty fields, etc. You have no choice to
code some protection for many control types.

I've also done ADO all by hand, and found that the overhead was
significantly less, and that performance was improved for many operations.
It also gives you more control over the process, better validation
potential, and access to many of the benefits of SQL Server (such as stored
procedures). Perhaps most importantly the solution can be built using
business objects that scale very efficiently. (For example, field by field
inserts into recordsets is brutally slow compared to SQL INSERT statements.
Being able to marshall the recordset on the client and transact a
parameterized INSERT will reduce network traffic significantly. At least,
this has been my experience.)

Perhaps the best solution though would be producing VB Class objects marked
as data providers. These classes could internally handle all operations in
code, and expose binding properties. It neatly separates the interface,
maintains the binding benefits, and gives you some robustness that might
otherwise be lost. The long-term benefits of this approach are reduced
overall maintenance on the GUI level, and an interface-independent data
layer.

You will definitely want to stick to a multi-tier architecture, regardless.
Of three MS SQL Server solutions I have led, one was bound to a flat
architecture that made it a brutal management experience. The other two were
distributed apps, offloading procedures to the engine and managing all data
in an isolated middle tier, with a complete separation of interface and data
layer. These both scale amazingly, and operate at blazing speed even on slow
networks.

Also, don't let the deadline alone dictate your choice. Time saved using
control bindings will be lost instantly if problems in the controls arise.

As an objective observer I would say that if the data sets are potentially
large, and you will be using the application in a networked space with
multi-user connection issues, you should either forgo the data bound
controls or create a data provider class model that works to reduce
connections to a minimum and handles the marshalling for updates in a
consolidated fashion.

Good luck.


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, 17 Aug 2002 03:00:00 GMT  
 Data-Bound Vs. Non-Data-Bound Controls
Take a look at Data-Aware classes.
The best source for learning the basics is "MS VB 6.0 Programmers Guide,
Programming with Objects, Ch 9." There are lots of articles on so called
advanced data binding, but the above is the best place to start. Keep in
mind a data control is inplemented using a VB class. You might also look
at "Visual Basic 6 Distributed Objects", Rocky Lhotka, but this is not
the place to start. It's pretty advanced stuff.

Dick Spence



Mon, 19 Aug 2002 03:00:00 GMT  
 
 [ 8 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