471,602 Members | 1,287 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,602 software developers and data experts.

Static vs Non Static DAL Class(es)

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!
Dec 26 '06 #1
10 8935
"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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 really struggling to come up with *any* possible advantages of a
non-static DAL...

My DAL has six methods:

GetDataSet
GetDataReader
GetScalar
ExecuteSQL
ExecuteSQLTransaction
WriteImage

all of which are overridden to support the passing in of a connection string
or reading it from the config file, and either a SQL string or the name of a
stored procedure plus parameters collection.

What else do you need your DAL to do...?
Dec 26 '06 #2
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.
--
Ignacio Machin
machin AT laceupsolutions com
"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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!

Dec 26 '06 #3
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.

--
Dave Sexton
http://davesexton.com/blog

"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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!

Dec 26 '06 #4


"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:Or**************@TK2MSFTNGP02.phx.gbl...
"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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 really struggling to come up with *any* possible advantages of a
non-static DAL...

My DAL has six methods:

GetDataSet
GetDataReader
GetScalar
ExecuteSQL
ExecuteSQLTransaction
WriteImage

all of which are overridden to support the passing in of a connection
string or reading it from the config file, and either a SQL string or the
name of a stored procedure plus parameters collection.

What else do you need your DAL to do...?
Wow, those methods almost look familiar. You may want to look into the
Microsoft Patterns and Practices Enterprise Library - Data Access
Application Block <pants, tries to breath>.

http://msdn.microsoft.com/practices/.../html/daab.asp

The P&P EL application blocks come with full source code, so you can
modify/add methods to better suit your needs...

HTH,
Mythran
Dec 26 '06 #5
Hi Mark,
I'm really struggling to come up with *any* possible advantages of a
non-static DAL...
I created a DAL for my applications that isn't static. It consists of a
generic class named, "DataAccessContext" (with some supporting classes). I
can derive from that class something like SqlDataAccessContext (which I
already have in my library). The DAL uses a custom .NET 2.0 Provider (for
WinForms or ASP.NET) to allow the future addition of other context providers
such as Oracle, which I haven't needed myself yet. In an application I can
then derive a class from SqlDataAccessContext to provide a typed
implementation of my DAL and with the generic arguments specify the typed
DataSet being used for my application so that all of the DAL members are
strong-typed. It supports transactions using those provided by the data
provider or even 2.0 System.Transactions.

I use it to perform operations against the database as such:

// "Data" is a common namespace that I use
// "data" is an instance of the application's strong-typed DataSet
using (Data.Context dataContext = new Data.TransactedContext(data))
{
dataContext.AddTableMapping("Users");
dataContext.Fill("SelectUsers");
}

--
Dave Sexton
http://davesexton.com/blog
Dec 26 '06 #6


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.
"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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!


Dec 26 '06 #7
"Mythran" <ki********@hotmail.comwrote in message
news:uq**************@TK2MSFTNGP04.phx.gbl...
The P&P EL application blocks come with full source code, so you can
modify/add methods to better suit your needs...
My DAL is based on the Microsoft one...
Dec 26 '06 #8
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.
Fred Mertz wrote:
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!
Dec 27 '06 #9
Mark Rae <ma**@markNOSPAMrae.comwrote:
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 really struggling to come up with *any* possible advantages of a
non-static DAL...
By making the DAL non-static, it can implement an interface which the
BOL then talks to after being configured with an implementation. For
production code this would be the normal DAL, but for unit test
purposes you can use mocks etc.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 27 '06 #10
Mark Rae wrote:
"Fred Mertz" <A@B.comwrote in message
news:u$**************@TK2MSFTNGP04.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 really struggling to come up with *any* possible advantages of a
non-static DAL...
Some people like object oriented programming.
My DAL has six methods:

GetDataSet
GetDataReader
GetScalar
ExecuteSQL
ExecuteSQLTransaction
WriteImage

all of which are overridden to support the passing in of a connection string
or reading it from the config file, and either a SQL string or the name of a
stored procedure plus parameters collection.

What else do you need your DAL to do...?
The above will work fine for many cases.

But some people have different requirements.

Like being able to switch DAL implementation without
changing code in BLL.

Arne
Dec 31 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by alexhong2001 | last post: by
4 posts views Thread by Tomas Ukkonen | last post: by
12 posts views Thread by James Brown | last post: by
8 posts views Thread by Stanislav Simicek | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by MichaelMortimer | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.