DAL...should the methods be static?

[H]

In my BusinessLogicLayer, there are many places where I call the
DataAccessLayer.

Is it better to have static methods in my DAL that are lock()'ed and
called directly from my BLL (thus the CLR takes care of concurrency)
or should I have public methods and create an instance of my DAL each
time it is used (thus let SQL Server take care of concurrency)?

adv-thanks-ance...

 

[HelloCode]

In my BusinessLogicLayer, there are many places where I call the
DataAccessLayer.

Is it better to have static methods in my DAL that are lock()'ed and
called directly from my BLL (thus the CLR takes care of concurrency)
or should I have public methods and create an instance of my DAL each
time it is used (thus let SQL Server take care of concurrency)?

adv-thanks-ance...

if you static methods use different connection is no problem.

 

[Mark Rae [MVP]]

I have used static methods extensively in my DAL without problems in a
multi user environment.

Me too.

 

[Peter Bromberg [C# MVP]]

The SqlHelper v2.0 class from Microsoft, which is considered "best practices"
code, has all static methods. In fact, even though it first came out in
2001, I still use it extensively.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short Urls & more: http://ittyurl.net

 

[sloan]

To provide another view...I write my DAL's as non static methods.

The one reason is that I have overloaded constructors....which are
() //empty
(string dbInstanceName)

I use the Enterprise.Data library....and it allows the use of a default
"instanceName"....or you can specify a specific named instance.
"SourceDatabase"
"DesinationDatabase"

or

"VirginiaDatabase"
"TennesseeDatabase"

whatever your multiple db needs might be.

I could have done this just as easily with overloaded static methods. But I
chose overloaded constructors instead.

...

If you are using SqlServer only...then the DAAB 2.0 is a great helper
library.

If you're using something besides Sql Server....or using SqlServer ~and~
another one...then I'd go EnterpriseLibrary.Data.

You can use the EnterpriseLibrary.Data with SqlServer only as well. But it
has has overhead code you might not need.

If you write a really good DAL layer..you should be able to swap out DAAB
2.0 for EnterpriseLibrary.Data with little effort.

...

Check here for a sample.
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry
I have a 1.1 example as well, and it uses the DAAB 2.0. Just look for it at
the blog.
(Custom Objects, ... .1.1)

 

[Just Me]

The only reason you need to lock them is if they are making use of a static
variable which you should avoid at all costs.

I have used static methods extensively in my DAL without problems in a multi
user environment.