What are the pros/cons of choosing between static and instance data access classes in a web app?

Asked 13 years, 10 months agoModified 13 years, 10 months agoViewed 9k times

I've read several other questions on this topic (here, here, and here), but have yet to see a great answer. I've
developed my fair share of data access layers before and personally prefer to use instance classes instead
of static classes. However, it is more of a personal preference (I like to test my business objects, and this
approach makes mocking out the DAL easier). I have used static classes to access the database before, but
I've always felt a little insecure in the appropriateness of such a design (especially in an ASP.NET
environment).

Can anyone provide some good pros/cons with regards to these two approaches to developing data access
classes with ADO.NET providers (no ORM), in an ASP.NET application in particular. Feel free to chime in if
you have some more general static vs. instance class tips as well.

In particular, the issues I'm concerned about are:

1. Threading & concurrency

2. Scalability

3. Performance
4. Any other unknowns

Thanks!
c# asp.net class-design data-access-layer

edited May 23, 2017 at 11:45 asked Jan 20, 2010 at 1:07
CommunityBot Kevin Babcock
1 1 10.2k 19 70 89

Static based approaches really typically have one, and only one, main advantage: they're easy to
implement.

Instance based approaches win for:

1. Threading and Concurrency - You don't need any/as much synchronization, so you get better
throughput
2. Scalability - Same issues as above

3. Perf. - Same issues as above

4. Testability - This is much easier to test, since mocking out an instance is easy, and testing static classes
is troublesome

Static approaches can win on:

1. Memory - You only have one instance, so lower footprint

2. Consistency/Sharing - It's easy to keep a single instance consistent with itself.

In general, I feel that instance-based approaches are superior. This becomes more important if you're going
to scale up beyond a single server, too, since the static approach will "break" as soon as you start instancing
it on multiple machines...
answered Jan 20, 2010 at 1:13
 Reed Copsey
556k 78 1165
1378
I think the pros far outweigh the cons, at least in my opinion. And as for Memory consumption, I think that is probably
a negligible downside in most applications. – Kevin Babcock Jan 28, 2010 at 15:55

1 @Kevin Babcock: I personally almost always try to use instance based approachs. If I want/need static, I usually go to a
singleton, since that's easier to adapt to a multiton or to an instance approach later (since you're still working with
instances...) – Reed Copsey Jan 28, 2010 at 16:34

why would static approach "break" as soon as you start instancing it on multiple machines? they all handling data in
their own memory space. am I missing something? – user20358 Oct 29, 2021 at 23:52

My general feeling is: Why instantiate if you don't have to?

I use static classes when there wont be any use for multiple instances and there isn't a need for instance
members. As for the DAL, the point is that there is only one. Why instantiate it if there is no value in it?

Look at this link, which shows that static method calls are faster than instance class method calls.

This link shows that an advantage of using a static class is that the compiler can check to make sure that no
instance members are accidentally added.

This link shows that a static class can be used as a convenient container for sets of methods that just
operate on input parameters and do not have to get or set any internal instance fields. For a DAL, this is
exactly what you have. There is no reason to create any internal instance fields, and therefore, no reason to
instantiate.
edited Jan 20, 2010 at 1:22 answered Jan 20, 2010 at 1:10
Gabriel McAdams
57.3k 12 63 77
1 There is a lot of value in instantiating. I personally feel the exact opposite: Only go static if there is a compelling reason
for the type/data/method/etc to be treated statically. – Reed Copsey Jan 20, 2010 at 1:14

My general feeling is: Why make it static when you don't need to? – user47589 Jan 20, 2010 at 1:15

@yoda and @Reed: You seem to feel that my answer is incorrect. In your opinion, what are the downsides to static
classes? – Gabriel McAdams Jan 20, 2010 at 1:24

3 Major downside (and I've seen it happen many times): as things get more complex over time, you end up with big
monolithic methods because all your state has to be passed as method args, since you can't (practically) use static fields
to store state in a multi-threaded app. As the complexity and depth grows, people get lazy and instead of
encapsulating something in a new method, everything gets stuffed inline, copied, pasted, looped, etc. Same thing can
happen with instance methods, but it's much easier to refactor with instance fields/properties. – nitzmahone Jan 20,
2010 at 1:54

2 @Nitz: That sounds like a downside to bad development practices, and the lack of code-reviews. – Gabriel McAdams
Jan 20, 2010 at 1:57

1 @Gabriel McAdams: Static classes have quite a few downsides for anything but very simple utility classes (ie:
System.Math). They tend to be more difficult in threaded scenarios, since you need extra locking. They're more difficult
to test, and to mock out when you need to do complex testing (very important for a DAL). They're less flexible, since
they break polymorphism. Basically, a static class locks you into a fixed, rigid design - in most cases, creating a class
non-static is much cleaner. Worst case, if you really want static, consider a singleton... – Reed Copsey Jan 20, 2010 at
16:39

I have been using a static DAL for years, and I agree with your concerns. Threading and concurrency is the
most challenging and in my case I store different connection objects in thread static structures. It has
proven to be very scalable and performs well, even more so now that I am converting PropertyInfo into
PropertyDescriptor which gives me the same benefits of reflection with better performance. In my DAL I
simply have to write:

List<Entity> tableRows = SQL.Read(new SearchCriteria(), new Table());

Everything spawns off the SQL static class, and that makes my code a lot simpler.
answered Jan 20, 2010 at 1:15
Otávio Décio
74k 17 161 228

What kind of concurrency issues have you run into with your approach? – Kevin Babcock Jan 28, 2010 at 15:56

The way I have it set up I run one connection object per thread. One concurrency issue I had to deal with was when you
insert a new object, get its generated primary key (from a sequence or identity) and populate the object's PK value - if
you are not careful you end up doing many inserts and getting the wrong sequence messing up the FK relationship.
– Otávio Décio Jan 28, 2010 at 20:40

For me the main reason is that I don't need to keep the state of that DAL object. The state of the objects it
uses don't span the scope of the method they are embeded. This way why would you keep multiple
instances of an object, if they are all the same?

With the latest versions of the ADO.NET, seems to be best practice to create and destroy the connection to
the database within the scope of your call, and let the ConnectionPool take care of the whole connection
reusability issue anyway.

Again with the latest versions of the .NET Framework, TransactionScope (which would be one reason to
manage your connections yourself) move up to the business level, which allow you to join multiple calls to
the DAL within the same Scope.

So I can't see a compeling case to create and destroy (or cache) instances of the DAL.
answered Jan 20, 2010 at 1:55
Wagner Silveira
1,576 11 9