One reason I use non static is
A: Constructor
B. I inherit from an abstract class.
class DataLayerAbstra ct
{
public DataLayerAbstra ct()
public DataLayerAbstra ct(string instanceName)
}
class EmployeeData : DataLayerAbstra ct
{
public EmployeeData : base ()
public EmployeeData (string instanceName) : base (instanceName)
}
class DepartmentData : DataLayerAbstra ct
{
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 DataLayerAbstra ct
{
public DataLayerAbstra ct()
public DataLayerAbstra ct(string instanceName)
public override DataSet GetAllEmployees ();
}
class EmployeeDataWit hAccess : DataLayerAbstra ct
{
public EmployeeData : base ()
public EmployeeData (string instanceName) : base (instanceName)
public override DataSet GetAllEmployees ()
{
//return a DataSet of employees via Access
}
}
class EmployeeDataWit hSqlServer : DataLayerAbstra ct
{
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 MyDatabaseFacto ry
{
private MyDatabaseFacto ry ()
{}//hide the contructor
public static DataLayerAbstra ct GetADataLayerOb ject()
{
bool isAccess = true;// config file? etc?
if (isAccess)
{
return new EmployeeDataWit hAccess ();
}
else
{
return new EmployeeDataWit hSqlServer ();
}
}
}
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 EnterpriseLibra ry.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.
"Fred Mertz" <A@B.comwrote in message
news:u$******** ******@TK2MSFTN GP04.phx.gbl...
I'm wondering what some of the important considerations are regarding
implementing the DAL as a static class vs creating instances of it as
needed.
I'm writing a .NET 2.0 Windows application (MDI) that will communicate
with
a SQL Server; approximately 120 users.
On smaller apps I have tended to implement the DAL as a static class. But
this new app will likely spawn background threads periodically to update
business objects throughout the session. All such threads (likely not more
than one or two at a time) would make use of the DAL.
This is my first foray into multi-threaded apps - so I'm wanting to
proceed
with caution and guidance. So any relevant would be appreciated!
