There are obviously many ways to this but we like to take the approach of seperating the Data Layer / Business Layer / Presentation Layer. We also often have the need for multiple UIs working on the same underlying Business Object - with databound controls you often find a lot of business logic tied into the GUI, making it difficult to easily create alternative GUIs. In addition, I suspect that databound controls may also complicate backend database independence. Also, with databound controls any small change to the database could have a direct impact on the GUI.
 
Just another view...
Xander
 
----- Original Message -----
Sent: Thursday, August 31, 2000 10:34 AM
Subject: Re: [DUG]: To Bind or Not to Bind

Jeremy
 
I use ADO and bound controls - I think 'people' use unbound control 'cause they can't get bound controls to work the way they want.
 
I take Max's approach - don't work around the problem (by unbinding your controls) - SOLVE THE PROBLEM
 
For scalable apps I use Client/Static/BatchOpt ADO (on MSSQL et al) and for small Server/Keyset/Opt (on JET) both work well - The main
advantage ADO has with bound controls and Client/Static/BatchOpt is that you now have a 2 stage commit process - posting to the dataset
and batch updating the server - this menas that speed and efficiency of the bound controls is not so much of an issue as they are only posting
to an in memory recordset
 
HTH
Neven
----- Original Message -----
Sent: Thursday, 31 August 2000 08:26
Subject: [DUG]: To Bind or Not to Bind

Hi all....just a follow-up to my original ADO question of a couple of days ago.....what are the advantages is not using DB Bound controls as apposed to non bound controls in an application.
I can think of a couple of fores and against for both senarios.....to me, not binding seems to be a lot of work....but does this increase flexability ??
Is it a speed issue ?
 
 
Interested to know why people went non bound instead of using bound controls etc.
 
Thanks,
 
 
Jeremy Coulter

Reply via email to