Data Access Logic Components

[Mark Gilkes]

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?
--
MG

[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!=Configur ation["MyAppConnectio nString"]) // The syntax if
off here, I"m going from memory, but the object which reads config file
AppSettings
{
this.m_connectS tring=Configura tion["MyAppConnectio nString"];
}
else
{
throw new ArgumentExcepti on("MyAppConnec tionString not defined in config
file");
}
}

//constructor2
public UserInfo(string connectString)
{

this.m_connectS tring=connectSt ring;

}

}
I actually don't do that anymore, as I use the EnterpriseLibra ry
dataconfigurati on.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 connectionStrin gs
as needed. The overloaded constructor does this, but has the "easy
constructor", if I don't send it in.
"Mark Gilkes" <ma*********@NO SPAMgmail.com> wrote in message
news:14******** *************** ***********@mic rosoft.com...

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?
--
MG

[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.Http Utility),
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,
--
Joerg Jooss
ne********@joer gjooss.de

[Mark Gilkes]

Mmm, thanks for your comments folks!