Hi,

I don't know how u plan to implement your DAL but as long as they are
stateless (most probably they are already) you should have no problem with
concurrency.

Hi Fred,

When using static methods with asynchronous processes you'll have to be sure
that they are thread-safe.  If the methods in your static classes don't rely
on any shared state then you won't have to worry about thread-safety in
managed code, at least.

Using instances of your DAL entities is more OO though, and therefore more
flexible.  You'll probably be better off using instances instead regardless
of whether thread-safety is an issue.  Objects will allow you to handle
entity relationships easily, and if you ever need to expand into a more
robust design pattern then you'll probably need instances of your entities
anyway (to facilitate the polymorphic techniques used by design patterns).
Static classes would just end up being a bottleneck in the development
process.

One reason I use non static is

A: Constructor
B.  I inherit from an abstract class.

class DataLayerAbstract
{
   public DataLayerAbstract()

   public DataLayerAbstract(string instanceName)

}

class EmployeeData : DataLayerAbstract
{
   public EmployeeData : base ()

   public EmployeeData (string instanceName) : base (instanceName)

}

class DepartmentData : DataLayerAbstract
{
   public DepartmentData : base ()

   public DepartmentData (string instanceName) : base (instanceName)

}

Something like that.  I have a few different ways I could instantiate the
object (mainly, from where do I get the connection string info).

Then I only write that code once, in the abstract class.

...........

If I ever have a need, where I might use Access or SqlServer, then I can do
something like this:

class DataLayerAbstract
{
   public DataLayerAbstract()

   public DataLayerAbstract(string instanceName)

   public override DataSet GetAllEmployees();

}

class EmployeeDataWithAccess : DataLayerAbstract
{
   public EmployeeData : base ()

   public EmployeeData (string instanceName) : base (instanceName)

   public override DataSet GetAllEmployees()
{
       //return a DataSet of employees via Access
}

}

class EmployeeDataWithSqlServer : DataLayerAbstract
{
   public EmployeeData : base ()

   public EmployeeData (string instanceName) : base (instanceName)

   public override DataSet GetAllEmployees()
{
       //return a DataSet of employees via Sql Server
}

}

Then I can write my code to work with the abstract class, and then create a
factory class to return either the sql server or access version.

pubic class MyDatabaseFactory
{
   private MyDatabaseFactory ()
{}//hide the contructor

public static DataLayerAbstract GetADataLayerObject()
{
       bool isAccess = true;// config file? etc?

     if (isAccess)
{
       return new EmployeeDataWithAccess ();
}
else
{
       return new EmployeeDataWithSqlServer ();
}
}
}

Forgive my syntax errors, but hopefully you get the idea.

I would use the "data access application block" 2.0 if you're using sql
server ... to ~~~help with and aid your DataLayer object(s).
If you have needs beyond Sql Server, then check the EnterpriseLibrary.Data
library.
This will do housekeeping for you on almost everything, except properly
closing an IDataReader.  You ~~always need to close the IDataReader
yourself, as soon as possible.

I'm not sure if you're creating a helper DAL object OR  DAL objects per
entity (as in, EmployeeData, DeptData, stuff like that)

Those are some reasons, each situation is different.

Instead of re-inventing the wheel....Have you thought about using a
time-tested DAL...  I would HIGHLY recommend LLBLGenPro
(http://llblgen.com) as the main developer is a MASTER when it comes to
DAL, and the support along with the number of people actually using it
in real world application makes it a very stable product.  I was using
DeKlarit, but found it difficult to use once a project got soo big.  I
since found LLBLGenPro and can't say enough about it.