database access pattern

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

How does everyone design the database access layer in an asp.net application?
Two options that come to mind is:

1. create a database class and instanciate it as needed, local to a function
or
2. Provide database access in a base class from which all objects that need
db access will inherit from.

#1 seems wasteful for application that do frequent but light db access.
Option #2 seems even more wasteful, because it adds overhead to the
inheriting class creation, whether or not that class will do db access.

The third option that I have been thinking about is a modification of 1, but
make it as a singleton. Would that help any, or will it become a bottleneck?

I'm just looking for pointers on best practives on implementing the database
layer. I found some in MSDN, but they were more implementation related,
rather than design related. I'd like to cut down on object creation, while at
the same time keep throughput as high as possible. Creating a database class
is usually expensive, since it involves retrieving a connection string,
setting up multiple objects, etc...

any ideas would be appreciated.
 
Definitely #1 and I do not like your singleton idea. Really you only need
one instance of a DAL so a singleton would work well. I would not think you
would want the data access to reside in the base for all your classes. Part
of design is to isolate the data access part into its own area, then have
the other classes call methods that returns specific pieces of information.
 
Val said:
How does everyone design the database access layer in an asp.net
application? Two options that come to mind is:

1. create a database class and instanciate it as needed, local to a
function or
2. Provide database access in a base class from which all objects
that need db access will inherit from.

#1 seems wasteful for application that do frequent but light db
access. Option #2 seems even more wasteful, because it adds overhead
to the inheriting class creation, whether or not that class will do
db access.

The third option that I have been thinking about is a modification of
1, but make it as a singleton. Would that help any, or will it become
a bottleneck?

I'm just looking for pointers on best practives on implementing the
database layer. I found some in MSDN, but they were more
implementation related, rather than design related. I'd like to cut
down on object creation, while at the same time keep throughput as
high as possible. Creating a database class is usually expensive,
since it involves retrieving a connection string, setting up multiple
objects, etc...
Click to expand...

object creation is very very fast in .NET, so #1 isn't a waste. Never
go for 'singletons' for dataaccess, it will likely limit the
scalability of your application as singletons should be either
immutable OR have locking functionality, which slows down application
flow.

FB

--
 
ValP.

Be aware that an ASPNET application is stateless and belongs to all clients.

It means that any data that you use static/shared will be shared by all
clients.

Therefore in my opinion is the best design that you get all (major)
datahandling in a static/shared class.

However keep the data itself (except never changing data) completely apart
in classes, which you have to instance at the load of a webpage.

There are other options, in my opinion very complex.
The major problem is that you never know when a user disconnect from your
application.

I hope this helps,

Cor
 
Ops, did not think about the "static" issue when I commented on the use of
singleton. For a desktop app singleton would work, but not in the web app
(or rather should be avoided).
 
Back
Top