Data Access Logic Components

[Guest]

I would just like to get a feeling for what others are doing here. Having
read through the 'Data Tiers' paper under MS's Paterns and Practices I am
designing and developing a small(ish) 3 layered web app. Now I've come to
design the DALC classes I cannot see any reason why I would make these
methods instance methods. It seems to me that they only need be static
methods. The DALC is purely a class definition with a bunch of methods that
call on stored procs and return DataSets. I can't see any reason for
constructor code here or any inheritance, therefore all these methods could
be static right?

 

[sloan]

One reason I use the constructor, is to be able to switch up which db I
might use.

Or instance.


class UserInfo
{
private string m_connectString = string.Empty;

//constructor1
public UserInfo()
{
//no connection string was given , so read it from the config
if (null!=Configuration["MyAppConnectionString"]) // The syntax if
off here, I"m going from memory, but the object which reads config file
AppSettings
{
this.m_connectString=Configuration["MyAppConnectionString"];
}
else
{
throw new ArgumentException("MyAppConnectionString not defined in config
file");
}
}

//constructor2
public UserInfo(string connectString)
{

this.m_connectString=connectString;

}

}


I actually don't do that anymore, as I use the EnterpriseLibrary
dataconfiguration.config, but I use the same concept.


Anyway, I am just posting a reason why you might consider a instaniated
object with multi constructors.

...

My code runs against multiple databases (where a database is a client, but
the clients all have copies of the same db model) ... since I write good
data layer objects, I like to be able to send in alternate connectionStrings
as needed. The overloaded constructor does this, but has the "easy
constructor", if I don't send it in.

 

[Joerg Jooss]

Thus wrote Mark,

I would just like to get a feeling for what others are doing here.
Having read through the 'Data Tiers' paper under MS's Paterns and
Practices I am designing and developing a small(ish) 3 layered web
app. Now I've come to design the DALC classes I cannot see any reason
why I would make these methods instance methods. It seems to me that
they only need be static methods. The DALC is purely a class
definition with a bunch of methods that call on stored procs and
return DataSets. I can't see any reason for constructor code here or
any inheritance, therefore all these methods could be static right?

IMHO, for anything other than the most trivial helper class (stuff like System.Web.HttpUtility),
stay clear of static classes. In OO development, there's one rather fool
proof way to run into trouble: *Not* using objects.

When your DAL consist only of static classes, there's no clean way to decouple
your business layer from them for test purposes or to replace them with a
different implementation (say SQL Server 2005 for Oracle). The latter may
never be relevant for your applicaton, but the former always is. A unit test
for a Method B() in a business component A that uses a data access component
shouldn't be really accessing the database, but use a mock implemetation
of the data access component that returns some well defined result. Otherwise
you're not testing your business component in isolation.

I also think that your assumption about never finding a use for inheritance
is wrong. Unless your DAL is utterly trivial, you'll quickly discover some
common functionality in your DAL. This will all end up in private or internal
static methods or yet another helper class, but not in any meaningful object
hierarchy.

Cheers,

 

[Guest]

Mmm, thanks for your comments folks!