Best Practices Question

[JimO]

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the
idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim

[sloan]

http://groups.google.com/group/micro...af85a2e6593dfa
I hit send before pasting the link
"JimO" <jo************@DEF-earthlink.net> wrote in message
news:0T*****************@newsread4.news.pas.earthl ink.net...

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the
idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim

[sloan]

The object itself shouldn't have db calls in it.

It should be an object, with properties , methods, and sometimes events.

In the datalayer, you will populate either a IDataReader or a DataSet, which
you will use to create your objects.

Then, I usually have another class, in the biz layer.

The biz layer will call the datalayer, it will get the IDataReader or
DataSet.

This class will then loop over the IDataReader or DataSet, to create your
objects.
Your objects should not be tied to a specific database, which is what you
will end up having going with the "integrated db route".

See my other post:

"JimO" <jo************@DEF-earthlink.net> wrote in message
news:0T*****************@newsread4.news.pas.earthl ink.net...

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the
idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim

[JimO]

Thanks for the help.

Jim
"sloan" <sl***@ipass.net> wrote in message
news:ef**************@TK2MSFTNGP05.phx.gbl...

http://groups.google.com/group/micro...af85a2e6593dfa

I hit send before pasting the link
"JimO" <jo************@DEF-earthlink.net> wrote in message
news:0T*****************@newsread4.news.pas.earthl ink.net...

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim

[Manohar Kamath]

A separation of business objects from data access layer is highly desired.
Your "layers" would look something like:

UI --> Business Objects --> Data Access --> DB (Stored procs, etc.)

This way, you can focus on pure busiess in BO, without having to worry about
how you will persist this data in the database.

--
Manohar Kamath
Editor, .netBooks
www.dotnetbooks.com
"JimO" <jo************@DEF-earthlink.net> wrote in message
news:0T*****************@newsread4.news.pas.earthl ink.net...

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the
idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim

[JohnAskew]

I just want to point out that there are rare occasions when custom business
objects are 'too complex' to have the CRUD in a DAL. In this case, we use the
traditional and still 'correct' pattern of putting CRUD behavior inside our
complex business objects. These can be XMLSerialized sent to a server,
deserialized and their CRUD used on the server. It is a rarely needed, but
viable and correct option.
The standard way is to use tiers and seperate concerns between the BLL and
DAL.

"Manohar Kamath" wrote:

A separation of business objects from data access layer is highly desired.
Your "layers" would look something like:

UI --Business Objects --Data Access --DB (Stored procs, etc.)

This way, you can focus on pure busiess in BO, without having to worry about
how you will persist this data in the database.

--
Manohar Kamath
Editor, .netBooks
www.dotnetbooks.com
"JimO" <jo************@DEF-earthlink.netwrote in message
news:0T*****************@newsread4.news.pas.earthl ink.net...

As a general rule, is it better to place database calls as part of the
object the operate on or just put all the calls in thier own namespace?

Ex
Dim userObject = New UserClass()

userObject.InsertUser()

Or

Dim DBCalls = New SystemDBCalls()
DBCalls.InsertUser(userObject)

I realize there are a few different ways you can code this but you get the
idea. Or perhaps this is just a matter of preference or function?

Thanks,
Jim