DAL Standard or Best Practices

[Jeff S]

Just wondering if it's standard practice to make DAL classes STATIC (in a
Windows Forms). Doing so would make sense to me because DAL methods are
typically called quite frequently - certainly the case for DAL "Helper"
classes - plus DAL objects/classes generally maintain no state. Seems like a
good case for STATIC classes to me.

It has been recommended to me to put the entire DAL, into a separate .DLL.
Is that standard practice too?

Thoughts? Opinions? Perspective?

Thanks!

[DKode]

i usually (75%), make my DAL classes static, unless I have some reason
to make it instance.

For instance, I recently created a DAL that handles SQL and Visual
FoxPro database calls. The SQL class is static, but the foxpro class I
made an instance because once I open the foxpro file, i usually run
quite a few sql statements before closing the connection. In this case
it is more effecient to keep the connection to the foxpro file while I
am running a batch of queries, rather than being a
connect-query-disconnect model.

I think it really depends on your needs. For something like my foxpro
class, i opted for a class instance instead of static methods.

Just my 2 cents

[Jon Skeet [C# MVP]]

Jeff S wrote:

Just wondering if it's standard practice to make DAL classes STATIC (in a
Windows Forms). Doing so would make sense to me because DAL methods are
typically called quite frequently - certainly the case for DAL "Helper"
classes - plus DAL objects/classes generally maintain no state. Seems like a
good case for STATIC classes to me.
That breaks any idea of using interfaces, however. I tend to use
dependency injection along with interfaces, such that the DAL classes
implement an interfaces and the BOL classes are provided with an
instance of the interface to use. In the production system, those
instances will be instances of the DAL classes. In unit testing,
however, I can provide mock implementations so that I can test my BOL
without needing a full DAL.
It has been recommended to me to put the entire DAL, into a separate .DLL.
Is that standard practice too?

It depends on the scenario, but it can be useful.

Jon

[Jeff S]

Thanks for providing your perspective.

Now, for a followup question - and please please PLEASE understand that I'm
NOT flaming or trying to be in any way pessimistic. I have been doing a lot
of research on patterns and best practices - from Microsoft, GoF, Martin
Fowler and others. I want to see the value in doing some of the advanced
techniques- but I'm having a hard time seeing the specific advantages and/or
value.
So here goes; RE:
<< In unit testing, however, I can provide mock implementations so that I
can test my BOL without needing a full DAL>>

I understand *what* you are saying - but what is the *advantage* of doing
this? How is it "worth it" for you to go through all the gyrations required
to do dependency injection and forego the use of STATIC DAL etc just so you
can test a business object without having a full DAL.

You have been doing this longer than I, so I'm hoping I can learn this
particular angle from your perspective.

-Jeff
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...

Jeff S wrote:

Just wondering if it's standard practice to make DAL classes STATIC (in a
Windows Forms). Doing so would make sense to me because DAL methods are
typically called quite frequently - certainly the case for DAL "Helper"
classes - plus DAL objects/classes generally maintain no state. Seems
like a
good case for STATIC classes to me.

That breaks any idea of using interfaces, however. I tend to use
dependency injection along with interfaces, such that the DAL classes
implement an interfaces and the BOL classes are provided with an
instance of the interface to use. In the production system, those
instances will be instances of the DAL classes. In unit testing,
however, I can provide mock implementations so that I can test my BOL
without needing a full DAL.

It has been recommended to me to put the entire DAL, into a separate
.DLL.
Is that standard practice too?

It depends on the scenario, but it can be useful.

Jon