3

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.

Community
  • 1
Superbest
  • 538
  • 1
  • 3
  • 12
  • Is this ASP.NET or Winforms? – MatthewMartin Nov 05 '12 at 18:57
  • @asd Winforms in this case. – Superbest Nov 05 '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 05 '12 at 20:09

2 Answers2

3

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.

HericDenis
  • 156
  • 3
  • So if multithreading is something I don't wish to preclude, what alternatives do I have to a static field? – Superbest Nov 05 '12 at 12:02
  • 1
    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](http://stackoverflow.com/questions/3867002/datatable-concurrency-locking), it should help. – HericDenis Nov 05 '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 05 '12 at 12:39
  • 1
    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 05 '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 05 '12 at 13:07
3

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)

MaximR
  • 363
  • 1
  • 7