Database programming

[Alan]

I am coming from other programming tools field, and new to VB .NET. Just
wondering what is the common approaching in database programming in VB .NET?

1) Are you guru always using the data aware controls to bound the database ?
OR
2) Create separate data object/layer to access backend database and link to
the front end ?
ie.
front <--> business <--> database <--> backend
end object layer database

[William Ryan]

There are different strategies for accessing data, but by and large, pulling
over the data you need and using a BindingManager/Context is a pretty
standard way of doing things.

1) Yes
2) Yes,
they are not mutually exclusive. All you need to bind is a
DataSet/DataTable (in ASP.NEt you can even bind a Grid to a dataReader).
How you get that DataSet is up to you. You can do it from the UI, you can
do it from your business objects, you can skip business objects altogether
(not recommended), you can have any layer you want query a web service
directly....which in turn can query the database.

You may want to pick up David Sceppa's ADO.NET Core Reference or Bill
Vaughn's ADO ADO.NET Best Practices...they both do a superb job of
addressing thesee issues. Also, Rhokford Lhotka has a Business Objects book
that has a much different, but very cool approach to doing business objects.

HTH,

Bill
"Alan" <NO**************@yahoo.com.au> wrote in message
news:uo**************@TK2MSFTNGP09.phx.gbl...

I am coming from other programming tools field, and new to VB .NET. Just
wondering what is the common approaching in database programming in VB ..NET?
1) Are you guru always using the data aware controls to bound the database ? OR
2) Create separate data object/layer to access backend database and link to the front end ?
ie.
front <--> business <--> database <--> backend
end object layer database

[David Browne]

"Alan" <NO**************@yahoo.com.au> wrote in message
news:uo**************@TK2MSFTNGP09.phx.gbl...

I am coming from other programming tools field, and new to VB .NET. Just
wondering what is the common approaching in database programming in VB ..NET?
1) Are you guru always using the data aware controls to bound the database ? OR
2) Create separate data object/layer to access backend database and link to the front end ?
ie.
front <--> business <--> database <--> backend
end object layer database

Certianly different people do it different ways. But I would say that there
is an emerging practice of using "bindable" business objects. ADO.NET makes
this very easy with it's disconnected and stongly typed datasets. Although
it's also possible to implement the interfaces that support databinding on
custom business objects.

The idea is that 1) and 2) are no longer the only choices. You can mix them
for a best-of-both-worlds approach. On the one hand a DataSet or DataView
does not have to be bound directly to your database. They are just
middleware data storage objects. And on the other the front end controls
can be bound to objects other than the intrinsic ADO.NET data storage and
retrevial objects. Custom objects can be made bindable too.

Here's where it gets more controversial. One thing I look for is ways to
add simplicity to applications, and I prefer a pay-as-you-go approach for
simple applications. It's just too hard to see into the future, and
therefore too easy to over-engineer a solution. Directly binding
applications to the database sure is simple. I think that for a simple
application you can do this "guiltlessly" since you can later interpose a
business object layer without too much disruption. Just have the new
business objects output the bindable objects that the UI expects.

David

[Alan]

I used to bind the dataaware controls in UI with the backend database with
dataset and datasource.

After reading messages from newsgroup about the framework/architecture, the
approach is using a business object. eg. customer business object,
encapsulte the attributes such as customer name, phone..etc, fetch the
values from the UI and pass itself into the database layer
(customed/dedicated database object for the backend database type eg.
oracle, ms sql server), the database layer execute the sql statement by code
or other database object in the tools.

So the database layer knows the business object, for example, it has a
method AddCustomer(CustomerObject), this method extract the attributes of
the CustomerObject and pass to the data binder or execute SQL : Insert
into... valuse (...).

As the same for FetchCustomer(CustomerObject), this method extract the
customer id from CustomerObject and execute the SQL like Select * from...
where id=... . Then by assigning the attributes back to the CustomerObject,
the UI can read back the attributes of CustomerObject.

I am coming from other programming tools field, and new to VB .NET. Just
wondering what is the common approaching in database programming in VB .NET?

1) Are you guru always using the data aware controls to bound the

database ?

OR
2) Create separate data object/layer to access backend database and link to

the front end ?
ie.
front <--> business <--> database <--> backend
end object layer database

Certianly different people do it different ways. But I would say that

there is an emerging practice of using "bindable" business objects. ADO.NET makes this very easy with it's disconnected and stongly typed datasets. Although it's also possible to implement the interfaces that support databinding on
custom business objects.

The idea is that 1) and 2) are no longer the only choices. You can mix them for a best-of-both-worlds approach. On the one hand a DataSet or DataView
does not have to be bound directly to your database. They are just
middleware data storage objects. And on the other the front end controls
can be bound to objects other than the intrinsic ADO.NET data storage and
retrevial objects. Custom objects can be made bindable too.

Here's where it gets more controversial. One thing I look for is ways to
add simplicity to applications, and I prefer a pay-as-you-go approach for
simple applications. It's just too hard to see into the future, and
therefore too easy to over-engineer a solution. Directly binding
applications to the database sure is simple. I think that for a simple
application you can do this "guiltlessly" since you can later interpose a
business object layer without too much disruption. Just have the new
business objects output the bindable objects that the UI expects.