Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have several instances of a class. Each instance stores data in a common database. So, I thought "I'll make the DataTable table field static, that way every instance can just add/modify rows to its own table field, but all the data will actually be in one place!"

However, apparently it's a bad idea to do use static fields, especially if it's databases: Don't Use "Static" in C#?

Is this a bad idea? Will I run into problems later on if I use it?

This is a small project so I can accept no testing as a compromise if that is the only drawback. The benefit of using a static database is that there can be many objects of type MyClass, but only one table they all talk to, so a static field seems to be an implementation of exactly this, while keeping syntax concise.

I don't see why I shouldn't use a static field (although I wouldn't really know) but if I had to, the best alternative I can think of is creating one DataTable, and passing a reference to it when creating each instance of MyClass, perhaps as a constructor parameter.

But is this really an improvement? It seems less intuitive than a static field.

share|improve this question
Is this ASP.NET or Winforms? –  MatthewMartin Nov 5 '12 at 18:57
@asd Winforms in this case. –  Superbest Nov 5 '12 at 19:48
Probably okay. Static fields are shared for an entire appdomain. If there is only one thread in that app domain that writes to that field, then you have race conditions and have to use the lock keyword. If this were ASP.NET using static fields would create race conditions as unrelated users read and write to the DataSet. –  MatthewMartin Nov 5 '12 at 20:09

3 Answers 3

up vote 3 down vote accepted

You wouldn't get any improvement if you pass an instance of the DataTable to each instance of MyClass, you still have a single DataTable instance every object refer to, and will use a bit more memory because each object will have that instance unlike a static field that is a single reference for the hole class.

For the first view, you shouldn't have any problems using this architecture, the problems can rise if you have multithreading and concurrent acesses to the DataTable.

share|improve this answer
So if multithreading is something I don't wish to preclude, what alternatives do I have to a static field? –  Superbest Nov 5 '12 at 12:02
You may still use the static field, there is no reason to use multiple DataTable objects if you have a single database, I think the way to go is using some locking method, take a look on this‌​, it should help. –  HericDenis Nov 5 '12 at 12:25
Thank you @Superbest, it's really rare to find people that mark your answer as the answer when it helps them (: Hope it really helps. –  HericDenis Nov 5 '12 at 12:39
Well, I gather that I'm not supposed to use statics although I don't quite understand why (besides your remarks). On the other hand, it makes more sense for me to use static in this case, as far as I can tell. So I guess I will just ignore the "no static fields" rule in this context unless someone feels like justifying why I shouldn't. Thanks for the link about locking! –  Superbest Nov 5 '12 at 12:53
I'm really not familiar with that "no static fields in C#", actualy, I disagree with this isolated sentence, static fields were made for being used, we just need to use them when it's use fits on a good design (that's my opinion and I'm not an expert in code design I'm just an Electrical Engineer that programs, I program for quite long time and learned all by myself from books and internet), so point that way and maybe someone post another opinion about that. –  HericDenis Nov 5 '12 at 13:07

Reading DataTable across multiple threads should be OK . Writing is not, you should synchronize write access. See "Thread Safety" in Data Table doc.
Might need to create a separate object that deals with data access and synchronization.

At the most basic though, you could just call lock(table) {//Write here} before you write the data in every thread.

Now, you shouldn't need to have a static variable to have it shared between instances, you could just set every thread to reference the same instance. This will give you more flexibility going forward (For example: to improve write performance you can have multiple connections and you can assign them from the pool every time a new thread is created)

share|improve this answer

You misunderstood that question/answer -- it is referring to static CLASSes, not fields. Although some of his comments about testing apply to fields as well.

As for the differences between passing it into the constructor vs a static field, the major difference is that inside the class, you know that the table is present. With a static class, it has to be created at some point, but you have no guarantee that it was created at the time the class was called (which is where your testing issue comes from). That means that you either have to test/create it inside the class wherever you use it, or the class has to trust that the sequence was done correctly.

With an actual instance of the table being passed in, you can be certain that the table is present when the instance was created, and you have a well defined point for any other verifications that you may need to make (number/names of columns, primary keys, number of rows, etc).

In addition, if you let the class itself initialize the table, which you will probably be tempted to do if you're checking in the constructor if the static field has been set, then the class has to have access to additional, unnecessary, information -- it has to be able to connect to the database and return the revelanvant rows or structure. One of the things that OOP is supposed to help with, is encapsulation -- keeping different parts of the system from being aware of, and depending upon, other parts. When designing a class, you always want it to do as little as possible to get the job done.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.