Databinding practice

[Jon]

We're taking our VB 6 application, which uses RDO and moving it to .Net 2.0.
We're doing this by recreating each form from the ground up, not using the
upgrade wizard. Our application has about 200 forms and our database has
over 150 tables and about 400 stored procedures. So, it's rather complex
and we use a lot of pretty complex joins, etc....

In our application, there are places where we use RDO Resultsets and loop
through data to populate text boxes and listviews, etc....and there are
other forms where used RDC controls and databinding. We moved away from the
RDC controls after running into lots of oddities and whatnot. New portions
of this app are now written without databinding, which I personally prefer.

We're deciding which route to go with .Net 2.0 and VB.Net...should we give
the databinding route another try with all the nice new control based data
objects or continue to use datareaders and datasets in code manually?

This is more a design question so I'd appreciate people's comments that have
more experience with .Net 2.0's data resources.

Thank you

 

[Cowboy \(Gregory A. Beamer\)]

I would take the time to tier out your project as you are going to have to
rework the binding, esp. from RDO. As for the manual versus object approach,
you can compromise without getting boxed in by using custom components. If I
had to choice between the "dataSource" objects and hand-coding, I would
personally hand code, as the "dataSource" object tightly bind your layers.
Yuck!

Hope this helps.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************

 

[W.G. Ryan - MVP]

Jon - I missed something. You're app isn't in .NET right now right? So
presently you're not using DataSets or Readers?

IMHO databinding is lightyears better/more reliable in .NET than it was in
VB6 but i'm hesitant to say that out loud at the risk of starting a
religious war. You can use the databinding syntax quite easily and
navigation got a lot easier in 2.0 but loading a dataset and rolling your
own binding will get you to the same place. In most cases this isn't
necessary as there's some pretty amazing stuff in place but i've met more
than a few vb6 programmers with such a bad taste in their mouth from
databinding that they don't really have any interest in it.

dataReaders are cool and all, but you can't remote them so if you're going
to use them, you probably want them on the back teir to fill a business
object and then pass the business object around - you'll bind to that. If
you're create a real n-tier app you wont' be binding to a reader or
accessing it directly from the UI layer.

HTH,

Bill

 

[Jon]

Correct, it's VB 6 right now. I've done a lot of work in .Net 1.1, mostly
on the ASP.Net side and a couple of very small winforms projects and I wrote
my own equivalent of Microsoft's DAAB, which I like using. Going that route
would keep us away from using data objects and we would simply create
readers and datasets and dataviews in code and do with them whatever we
need.

Using the data objects frightens me a little just because of the pain it was
in RDO and I want to make sure our new app version is built so it's easily
upgradeable to whatever comes after .Net 2.

I'm probably going to put my vote on not using the data objects, but I still
want to get as full an idea as possible of their pros and cons in a somewhat
large application.