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
