Static v Instance in DAL

[RichB]

I am slightly confused regarding when to use an instance method and when to
use a static method, particularly in the context of a DAL.

I have basically got a class which has methods for CRUD, an object passed
into the method an I return an object representing the outcome of the
operation or in the casse of a search a Data Transfer Object. Each of my
methods are static within an abstract Data Access Class, but I could of
course instantiate an object and use it's methods. In a couple of teching
examples I have seen instantiation of the Data Access Object.

Am I using static methods appropriately? Where is the line drawn between
instantiating an object an using it's methods and using an abstract object
to perform static operations?

Many thanks,
Richard

 

[Guest]

Generally speaking, utilty methods are candidates for being made static. For
example, if you look at the DAAB v2 "SqlHelper" class, everything is static.
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Guest]

OP seems to think he can only have static methods in an abstract class. Of
course, that is not the case and I am thinking he probably doesn't need nor
want his class with static methods to be abstract! Not sure what to point him
to for reference material.

 

[Guest]

RichB,

You do not need to instantiate a class nor use an abstract class for static
methods. No matter what class a static method is in you can reference/call it
via <classname>.<methodname>(<any paramaters>). Hope this helps.

 

[sloan]

One reason I got the non-static route is because I have 2 or 3 ways I might
use an alternate connection string.


public abstract class DataLayerBase
{

private string _instanceName = string.Empty;

public DataLayerBase()
{ }

public DataLayerBase(string instanceName)
{
this._instanceName = instanceName;
}

protected Database GetDatabase()
{
Database returnDb = null;
if (this._instanceName.Length > 0)
{
returnDb =
DatabaseFactory.CreateDatabase(this._instanceName);
}
else
{
returnDb = DatabaseFactory.CreateDatabase();
}
return returnDb;
}
}



public class ZebraData : DataLayerBase // all DAL objects inherit from
DataLayerBase
{
//Procedures
private readonly string PROC_ZEBRA_GET_ALL =
"[dbo].[uspZebraGetAll]";

public ZebraData() : base()
{
}

public ZebraData(string instanceName) : base(instanceName)
{
//use a named connection string
}

public IDataReader ZebraGetAll()
{
IDataReader idr = null;
try
{
Database db = base.GetDatabase();
DbCommand dbc =
db.GetStoredProcCommand(this.PROC_ZEBRA_GET_ALL);
idr = db.ExecuteReader (dbc);
return idr;
}
finally
{
}


}
}


So I can use the "defaultDatabase", when I call the empty constructor, or
use one of the named connection strings when calling the constuctor with one
string argument.

Obviously, you can do this via overloaded static methods as well. I just
chose the instantiated route.
I actually have a third overload, (not shown), because I created this small
"DatabaseCreationArgs", which allow you to set up parameters like
"ExcelFileName", and give you a well formed Excel connection string.

Aka, I have a third constructor...(not seen).


Obviously Im using the EnterpriseLibrary.Data to do my dataaccess as well.

Anyway, just giving you a food for thought about this.

I often debate which to do, but I went with this one. Aka, I think about
just using static methods, and the overloads, but I also want clear intent
for maintenance reasons

 

[RichB]

Thanks, I guess that there are no hard and fast rules, which means gives me
greater flexibility of thought.

Many thanks,
Richard

One reason I got the non-static route is because I have 2 or 3 ways I
might use an alternate connection string.


public abstract class DataLayerBase
{

private string _instanceName = string.Empty;

public DataLayerBase()
{ }

public DataLayerBase(string instanceName)
{
this._instanceName = instanceName;
}

protected Database GetDatabase()
{
Database returnDb = null;
if (this._instanceName.Length > 0)
{
returnDb =
DatabaseFactory.CreateDatabase(this._instanceName);
}
else
{
returnDb = DatabaseFactory.CreateDatabase();
}
return returnDb;
}
}



public class ZebraData : DataLayerBase // all DAL objects inherit from
DataLayerBase
{
//Procedures
private readonly string PROC_ZEBRA_GET_ALL =
"[dbo].[uspZebraGetAll]";

public ZebraData() : base()
{
}

public ZebraData(string instanceName) : base(instanceName)
{
//use a named connection string
}

public IDataReader ZebraGetAll()
{
IDataReader idr = null;
try
{
Database db = base.GetDatabase();
DbCommand dbc =
db.GetStoredProcCommand(this.PROC_ZEBRA_GET_ALL);
idr = db.ExecuteReader (dbc);
return idr;
}
finally
{
}


}
}


So I can use the "defaultDatabase", when I call the empty constructor, or
use one of the named connection strings when calling the constuctor with
one string argument.

Obviously, you can do this via overloaded static methods as well. I just
chose the instantiated route.
I actually have a third overload, (not shown), because I created this
small "DatabaseCreationArgs", which allow you to set up parameters like
"ExcelFileName", and give you a well formed Excel connection string.

Aka, I have a third constructor...(not seen).


Obviously Im using the EnterpriseLibrary.Data to do my dataaccess as well.

Anyway, just giving you a food for thought about this.

I often debate which to do, but I went with this one. Aka, I think about
just using static methods, and the overloads, but I also want clear intent
for maintenance reasons

I am slightly confused regarding when to use an instance method and when
to use a static method, particularly in the context of a DAL.

I have basically got a class which has methods for CRUD, an object passed
into the method an I return an object representing the outcome of the
operation or in the casse of a search a Data Transfer Object. Each of my
methods are static within an abstract Data Access Class, but I could of
course instantiate an object and use it's methods. In a couple of teching
examples I have seen instantiation of the Data Access Object.

Am I using static methods appropriately? Where is the line drawn between
instantiating an object an using it's methods and using an abstract
object to perform static operations?

Many thanks,
Richard

 

[Niels Ull]

One major advantage of not using static methods is that it allows you to
replace/stub out the functionality for unit testing without a database.
Or you can use different DAL implementations for Sql Server, Oracle, XML etc.

 

[sloan]

Another good point.

In fact, take a look here:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/19c9b0924188effa