Are people using data binding now?

[Larry Lard]

In the old days (VB3 era), there was a thing called the Data Control,
and you could use it to databind controls on forms to datasources, and
so (as the marketing speak goes), 'create database applications without
writing a single line of code!!!'. Personally, and I know I wasn't
alone in this, I was always suspicious of this claim, because one
invariably ended up writing huge amounts of code attempting to get the
automagical thing to do what you wanted.

For this reason a lot of real world apps ended up 'rolling their own'
database access, and avoiding direct binding like the plague - get your
recordset on your own terms, populate the controls yourself, do cancels
and updates yourself, no worries.

Each successive new MS language version or data access tech has always
trumpeted the amazing new benefits of the latest data binding system
(usually with some blurb about not having to write any code), and .NET
and 2.0 are no exceptions. There seems now to be a huge amount of data
access stuff closely coupling ADO.NET and WinForms controls.

The question is, is now the time to start adopting it in the real
world? Or are we still better off doing it manually, where we can be
sure what's actually happening?

--
Larry Lard
Replies to group please

[Carlos J. Quintero [VB MVP]]

I personally have always done it on my own, without any databinding provided
by the tools or controls. In the old days you lost a lot of control and
after several versions hearing the same thing, I don´t pay any attention to
automatic binding any more. Also, connecting to a data source from the user
interface bypasses the business objects. In some views, a DataSet/Recordset
should not reach a form. The DAO / ODBC / RDO / ODBC Direct / OLEDB / ADO /
ADO .NET 1.0 / ADO.NET 2.0 history has not helped too...

There was an attempt from MS to conciliate the UI, the business layer and
the datasources named ObjectSpaces but AFAIK it was cancelled due to
performance problems.

So, yes, in the VB4 show we were told the programmers wouldn´t be needed any
more to build data apps, but 10 years later here we are still doing the same
thing... ;-)

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com
"Larry Lard" <la*******@hotmail.com> escribió en el mensaje
news:11**********************@g44g2000cwa.googlegr oups.com...

In the old days (VB3 era), there was a thing called the Data Control,
and you could use it to databind controls on forms to datasources, and
so (as the marketing speak goes), 'create database applications without
writing a single line of code!!!'. Personally, and I know I wasn't
alone in this, I was always suspicious of this claim, because one
invariably ended up writing huge amounts of code attempting to get the
automagical thing to do what you wanted.

For this reason a lot of real world apps ended up 'rolling their own'
database access, and avoiding direct binding like the plague - get your
recordset on your own terms, populate the controls yourself, do cancels
and updates yourself, no worries.

Each successive new MS language version or data access tech has always
trumpeted the amazing new benefits of the latest data binding system
(usually with some blurb about not having to write any code), and .NET
and 2.0 are no exceptions. There seems now to be a huge amount of data
access stuff closely coupling ADO.NET and WinForms controls.

The question is, is now the time to start adopting it in the real
world? Or are we still better off doing it manually, where we can be
sure what's actually happening?

--
Larry Lard
Replies to group please

[Jim Wooley]

I have migrated a descent sized application and ripped out my old data
binding and replaced it with the Object-BindingSource solution. Overall, I
have been satisfied. I found a few kinks, but they weren't show stoppers.

In the past, I avoided the binding as I have been bitten too many times with
binding to bad historical data which would cause the form to crash with
little information as to what the source of the problem was. What's more, it
was difficult to interject your business logic when directly binding the
form with the data source.

Now with partial classes and datasets, or entity objects binding to the UI,
retaining the business rules is greatly simplified. The amount of code I
need to write in the UI is now significantly reduced (not eliminated yet). I
would still argue against directly binding the UI to the dataset without
leveraging the partial class support to enforce business rules for any data
entry system.

Jim Wooley

"Larry Lard" <la*******@hotmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

In the old days (VB3 era), there was a thing called the Data Control,
and you could use it to databind controls on forms to datasources, and
so (as the marketing speak goes), 'create database applications without
writing a single line of code!!!'. Personally, and I know I wasn't
alone in this, I was always suspicious of this claim, because one
invariably ended up writing huge amounts of code attempting to get the
automagical thing to do what you wanted.

For this reason a lot of real world apps ended up 'rolling their own'
database access, and avoiding direct binding like the plague - get your
recordset on your own terms, populate the controls yourself, do cancels
and updates yourself, no worries.

Each successive new MS language version or data access tech has always
trumpeted the amazing new benefits of the latest data binding system
(usually with some blurb about not having to write any code), and .NET
and 2.0 are no exceptions. There seems now to be a huge amount of data
access stuff closely coupling ADO.NET and WinForms controls.

The question is, is now the time to start adopting it in the real
world? Or are we still better off doing it manually, where we can be
sure what's actually happening?

--
Larry Lard
Replies to group please

[CMM]

I wholeheartedly disagree with this post. It sounds like it was borne out of
lack of experience with databinding.

1) For entity objects (as opposed to datasets) you really loose no
control... particularly if you give your objects <property>Changed events
which are used by the databinding infrastructure.

2) Datasets are extraordinarily suited for databinding. Particularly because
its ColumnError/RowError features allow you to communicate results to the
user (by coupling it to the ErrorProvider control for the form-as-a-whole...
or simply the built in features of datagrid or datagridview or any 3rd party
grids).

3) Datasets and "business rules." Even in VS2003 this wasn't that hard to
do. While it was difficult to "extend" the datasets themselves (because of
code re-generation), there was nothing keeping you from having a
complimentary "Validator" sibling (or wrapper) class subscribe to events
generated by the dataset and enforce "business rules." And, now in 2005 that
datasets can be extended with partial classes to provide this in the dataset
itself.... well, nuff said.

4) UI data-bound Master/Details and dataset position navigation was a little
"unintuitive" in 2003 because of the BindingContext/CurrencyManager objects
of the form that few people understood. MS solved this by wrapping them up
in an actual control BindingSource/BindingNavigator... to hit people over
the heads like "duh! this is how you use it!"

In short... it's EASIER to jump in and do all your stuff yourself.... AT
FIRST. But if you bother to take the time to learn about the infrastructure
already built exactly for that purpose you will save oodles of time in the
future and your programs will be much easier to upgrade and maintain.

[CMM]

With the exception of the 2005's new TableAdapter object (which takes an
extraordinary step BACK to VB.Classic days) .NET's binding, datasets,
datasources are all atomic and standalone "things." Databinding has nothing
to do with ADO.NET! In fact, datasets have nothing to do with databases. A
lot of people may make these connections in their brains... but in reality
it isn't true. You can write a 100% Dataset dependent / UI Databinding
application that doesn't do a single connection to a "database." Instead
your "DataAdapters" can (and should) live in another "tier" either locally
in dll's (which people like to lazily do) or on a separate server and
accessed via Remoting.

I think Microsoft has done a HUGE disservice by hiding (knocking it off the
toolbox by default) the DataAdapter and instead promoting the ill-conceived
"TableAdapter" (which is really just a wrapper around a DataAdapter). It is
sure to confuse VB6'ers joining at this point in time and lead to even MORE
confusion and misunderstanding of how data access actually works in .NET.

[Dennis]

I ask a question on this newsgroup before "has anyone used databinding of a
database in a COMMERCIAL application that they have actually marketed?". I
got many replies that databinding was great and some that it was a pain and
useless in commercial applications. Not one person responded "yes" that he
had used databinding to a database in a commercial application. Have you?
--
Dennis in Houston
"CMM" wrote:

I wholeheartedly disagree with this post. It sounds like it was borne out of
lack of experience with databinding.

1) For entity objects (as opposed to datasets) you really loose no
control... particularly if you give your objects <property>Changed events
which are used by the databinding infrastructure.

2) Datasets are extraordinarily suited for databinding. Particularly because
its ColumnError/RowError features allow you to communicate results to the
user (by coupling it to the ErrorProvider control for the form-as-a-whole...
or simply the built in features of datagrid or datagridview or any 3rd party
grids).

3) Datasets and "business rules." Even in VS2003 this wasn't that hard to
do. While it was difficult to "extend" the datasets themselves (because of
code re-generation), there was nothing keeping you from having a
complimentary "Validator" sibling (or wrapper) class subscribe to events
generated by the dataset and enforce "business rules." And, now in 2005 that
datasets can be extended with partial classes to provide this in the dataset
itself.... well, nuff said.

4) UI data-bound Master/Details and dataset position navigation was a little
"unintuitive" in 2003 because of the BindingContext/CurrencyManager objects
of the form that few people understood. MS solved this by wrapping them up
in an actual control BindingSource/BindingNavigator... to hit people over
the heads like "duh! this is how you use it!"

In short... it's EASIER to jump in and do all your stuff yourself.... AT
FIRST. But if you bother to take the time to learn about the infrastructure
already built exactly for that purpose you will save oodles of time in the
future and your programs will be much easier to upgrade and maintain.

[CMM]

"Commercial application?" Commercial to me means shrink-wrapped and sold in
stores. I work in New York / Wall Street and have worked or seen oodles of
"custom" financial services, trading front-ends, and custom CRM VB
applications. Almost all of the newer .NET projects use databinding (as well
as true n-Tier infrastructure via Remoting or .NET ComponentServices). The
older VB.Classic applications (and there are A LOT of them) do not.

[Dennis]

I am talking about "shrink wrapped and sold commercially".
--
Dennis in Houston
"CMM" wrote:

"Commercial application?" Commercial to me means shrink-wrapped and sold in
stores. I work in New York / Wall Street and have worked or seen oodles of
"custom" financial services, trading front-ends, and custom CRM VB
applications. Almost all of the newer .NET projects use databinding (as well
as true n-Tier infrastructure via Remoting or .NET ComponentServices). The
older VB.Classic applications (and there are A LOT of them) do not.

[CMM]

>"Not one person responded "yes" that he had used databinding to a

database in a commercial application."

Well, most commercial programs don't use "databases" because most consumers
don't have a "database engine" on their computers... instead commercial apps
use flat binary proprietary datafiles. The beauty of .NET is that you don't
need databases to do databinding.

Besides, had any of them actually ever written a "commercial" application?
Funny. I have. I wrote a program once that was sold commercially for a time.
Day-Timer Student Organizer sold between 1998-2000 at Staples and Target,
and stuff. It did not use databinding. Then again it was based on old messy
code I had written earlier in college (Simona Planner) and it did not use a
"database" but binary datafiles I structured myself.

I did have to support over 15,000 users and 4 platforms (Win95,98,ME,and
2000... you'd be surprised how hard that is)... and the things I learned on
that project led me to some of the practices "Cor" the MVP here deems
unnecessarily-strict and COBOL-like. If I were to rewrite it now in .NET 2.0
it would most definately use databinding (where applicable).

[CMM]

Hey Carlos, another Carlos here... just wanted to say MZ-Tools was a dear
part of my life for years. Those tools saved my life and my sanity so many
times.

--
-C. Moya
www.cmoya.com

[97T]

Can you recommend a book?

Thanks,

--NinerSevenTango--
"CMM" <cm*@nospam.com> wrote in message
news:ed**************@TK2MSFTNGP15.phx.gbl...

With the exception of the 2005's new TableAdapter object (which takes an
extraordinary step BACK to VB.Classic days) .NET's binding, datasets,
datasources are all atomic and standalone "things." Databinding has
nothing to do with ADO.NET! In fact, datasets have nothing to do with
databases. A lot of people may make these connections in their brains...
but in reality it isn't true. You can write a 100% Dataset dependent / UI
Databinding application that doesn't do a single connection to a
"database." Instead your "DataAdapters" can (and should) live in another
"tier" either locally in dll's (which people like to lazily do) or on a
separate server and accessed via Remoting.

I think Microsoft has done a HUGE disservice by hiding (knocking it off
the toolbox by default) the DataAdapter and instead promoting the
ill-conceived "TableAdapter" (which is really just a wrapper around a
DataAdapter). It is sure to confuse VB6'ers joining at this point in time
and lead to even MORE confusion and misunderstanding of how data access
actually works in .NET.

[CMM]

Correction: the app sold about 40,000 units. About 15,000 users sent in
their marketing dept "registration" info.

--
-C. Moya
www.cmoya.com
"CMM" <cm*@nospam.com> wrote in message
news:OE**************@TK2MSFTNGP10.phx.gbl...

"Not one person responded "yes" that he had used databinding to a
database in a commercial application."

Well, most commercial programs don't use "databases" because most
consumers don't have a "database engine" on their computers... instead
commercial apps use flat binary proprietary datafiles. The beauty of .NET
is that you don't need databases to do databinding.

Besides, had any of them actually ever written a "commercial" application?
Funny. I have. I wrote a program once that was sold commercially for a
time. Day-Timer Student Organizer sold between 1998-2000 at Staples and
Target, and stuff. It did not use databinding. Then again it was based on
old messy code I had written earlier in college (Simona Planner) and it
did not use a "database" but binary datafiles I structured myself.

I did have to support over 15,000 users and 4 platforms (Win95,98,ME,and
2000... you'd be surprised how hard that is)... and the things I learned
on that project led me to some of the practices "Cor" the MVP here deems
unnecessarily-strict and COBOL-like. If I were to rewrite it now in .NET
2.0 it would most definately use databinding (where applicable).

[CMM]

"97T" <no*@spamthis.com> wrote in message
news:ei**************@TK2MSFTNGP15.phx.gbl...

Can you recommend a book?

I tend to like the "Core References." ADO.NET Core Reference from Microsoft
Press was a great help when I was transitioning from VB6 to VS2003.

But, no other book was more INVALUABLE to me in the move to VB.NET in
general as Dan Appleman's "Moving to VB.NET." Yes, that Dan Appleman... the
VB / Win32 API God... who probably single-handedly set the stage for
VB3/4/5/6 to become the hugely popular development platform it became... by
pushing it out of its out-the-box limitations.

--
-C. Moya
www.cmoya.com

[Cor Ligthert [MVP]]

Jim,

Yours and the comments from Dennis sounds for me as those from people who
avoided in past methods as the for loops, the do while an do until etc
like this.

They told that it should only be done with GO TO. Because they had some
errors in past with those other commands.

As I told to Dennis before this kind of GO TO programs we see probably still
in huge commercial applications at Insurance companies and those like that,
where an error from one cent can mean billions and therefore they want to
stay often with there old proven programs.

Binding in Net is at the moment at a very high level, however with not any
programming style there can be avoided right testing (as I wrote as well to
Dennis). It has nothing to do with where something is used. That they use
probably still in very huge commercial applications the GO TO, does not mean
that you should not use a for or whatever loop. It has nothing to do with
that and is answering the same as on the question "Who know where kids come
from".

For the rest do I not have much to add what CMM wrote already (beside the
part he knows and is not important for this question, it is not the part
others think).

Just my idea.

Cor

[Carlos J. Quintero [VB MVP]]

"CMM" <cm*@nospam.com> escribió en el mensaje
news:uR**************@TK2MSFTNGP09.phx.gbl...

Hey Carlos, another Carlos here... just wanted to say MZ-Tools was a dear
part of my life for years. Those tools saved my life and my sanity so many
times.
Hi Carlos,

There are MZ-Tools for VS.NET 2002/2003 and VS 2005 if you want to try, some
MZ-Tools 3.0 features no longer apply in .NET, but there are new ones and
they still can save your sanity many times.

About your disagreeing post:
In short... it's EASIER to jump in and do all your stuff yourself.... AT
FIRST. But if you bother to take the time to learn about the
infrastructure already built exactly for that purpose you will save oodles
of time in the future and your programs will be much easier to upgrade and
maintain.

Maybe you are right and I should take another look, but changing the
database technology every year was not very helpful and I gave up long time
ago. I was about to try again learning about ObjectSpaces (or whatever it
was named) when I heard that it was cancelled...

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com

[Paul Clement]

On 8 Feb 2006 06:35:44 -0800, "Larry Lard" <la*******@hotmail.com> wrote:

¤ In the old days (VB3 era), there was a thing called the Data Control,
¤ and you could use it to databind controls on forms to datasources, and
¤ so (as the marketing speak goes), 'create database applications without
¤ writing a single line of code!!!'. Personally, and I know I wasn't
¤ alone in this, I was always suspicious of this claim, because one
¤ invariably ended up writing huge amounts of code attempting to get the
¤ automagical thing to do what you wanted.
¤
¤ For this reason a lot of real world apps ended up 'rolling their own'
¤ database access, and avoiding direct binding like the plague - get your
¤ recordset on your own terms, populate the controls yourself, do cancels
¤ and updates yourself, no worries.
¤
¤ Each successive new MS language version or data access tech has always
¤ trumpeted the amazing new benefits of the latest data binding system
¤ (usually with some blurb about not having to write any code), and .NET
¤ and 2.0 are no exceptions. There seems now to be a huge amount of data
¤ access stuff closely coupling ADO.NET and WinForms controls.
¤
¤ The question is, is now the time to start adopting it in the real
¤ world? Or are we still better off doing it manually, where we can be
¤ sure what's actually happening?

The main difference between the data binding of old and now is that it is also supported by the
ADO.NET classes and not just the Form controls. There is also considerably more flexibility, but the
lack of understanding with respect to how the classes work with one another will trip up a novice
who expects something to "just work" without issue. The fact that the internal functionality is
heavily obscured can make it even more challenging (kind of like the rest of .NET ;-)).

I don't think you can really avoid data binding in .NET, nor should you attempt to.
Paul
~~~~
Microsoft MVP (Visual Basic)

[97T]

Thanks!

--97T--
"CMM" <cm*@nospam.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

"97T" <no*@spamthis.com> wrote in message
news:ei**************@TK2MSFTNGP15.phx.gbl...

Can you recommend a book?

I tend to like the "Core References." ADO.NET Core Reference from
Microsoft Press was a great help when I was transitioning from VB6 to
VS2003.

But, no other book was more INVALUABLE to me in the move to VB.NET in
general as Dan Appleman's "Moving to VB.NET." Yes, that Dan Appleman...
the VB / Win32 API God... who probably single-handedly set the stage for
VB3/4/5/6 to become the hugely popular development platform it became...
by pushing it out of its out-the-box limitations.

--
-C. Moya
www.cmoya.com

[Jim Wooley]

Hello Cor Ligthert [MVP],

Jim,

Yours and the comments from Dennis sounds for me as those from people
who avoided in past methods as the for loops, the do while an do
until etc like this.

They told that it should only be done with GO TO. Because they had
some errors in past with those other commands.

As I told to Dennis before this kind of GO TO programs we see probably
still in huge commercial applications at Insurance companies and those
like that, where an error from one cent can mean billions and
therefore they want to stay often with there old proven programs.

Binding in Net is at the moment at a very high level, however with not
any programming style there can be avoided right testing (as I wrote
as well to Dennis). It has nothing to do with where something is used.
That they use probably still in very huge commercial applications the
GO TO, does not mean that you should not use a for or whatever loop.
It has nothing to do with that and is answering the same as on the
question "Who know where kids come from".

For the rest do I not have much to add what CMM wrote already (beside
the part he knows and is not important for this question, it is not
the part others think).

Just my idea.

Cor
Yours and the comments from Dennis sounds for me as those from people
who avoided in past methods as the for loops, the do while an do
until etc like this.

They told that it should only be done with GO TO. Because they had
some errors in past with those other commands.

Cor, this response is hitting below the belt and was uncalled for. My response
was advocating using the new binding. I have had minor issues with it, but
it is definately improved.

As for using GoTo and avoiding looping constructs, I haven't done that since
my Commodore 128 days. Please watch how you generalize responses. If you
have a problem with the recommendations and my tone in general, feel free
to take it up with me personally, not in public in the newsgroups. My address
isn't too hard to find.

Jim Wooley

[CMM]

Man, I loved my C128.
I don't think I have ever had such strong emotional feelings for a piece of
hardware since. I still remember exactly how the inset reset button on the
side felt and snapped back after you pushed it. How the screen blinked when
you switched to C64 mode. I remember every nuance of that machine. The C128D
looked like a PC... but the original C128 was sheer beauty and sexiness...
like a corvette.

OK. I'll stop now.

:-)

--
-C. Moya
www.cmoya.com

[Cor Ligthert [MVP]]

Jim,

I was not telling that you are using GO TO's. The point is that this kind of
discussions become often emotional, based on bad experiences in past or from
heard about that from others.

I took especially GO TO, because that is now out of the discussion.

In my opinion there is nothing against binding and surely not what can be
against trying a binding in whatever application.

This was surely not meant to you, more to a discussion in past about this
subject where was as well Dennis in involved. Maybe was that to much in my
mind when I was reading your message.

There was not any way of attacking you (why would I), not above or under the
belt.

If you have read it in any attacking way than Sorry, seems that I wrote it
wrong.

Cor