C# Static Access – Static DataTable or DataSet in a Class: Bad Idea?

ado.netcstatic-access

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.

Best Answer

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.

Related Solutions

Java Concurrency – Handling Static Objects in a Web Application

Those are basically solved problems. Just create a new connection every time you need to access the database (or maybe just once per request, if that's easily possible), and use a database API that supports pooled connections. Just make sure you close all connections no matter what, but that's something you should be doing anyway. No need to reinvent the wheel here.

And may I note that making the database connection a singleton is a bad design decision in the first place, because of the exact problem you've run into. There is absolutely no reason to enforce that there is only ever one connection to the database from your application.

C# – Unity Dependency Injection and Helper functions

Your questions sounds a little bit confused about Validate being a function or a class, but for sake of simplicity, let us assume it is a function.

If I got you right, you want to make sure your Validate function uses internally the same ISystemSettingService object as MyController. Passing it as a parameter like

 Validate(userData, _systemSettingService)

at all places where is Validateis called is surely a working approach. However, by making Validate non-static, you can actually reach the same goal in a more readable and less error-prone fashion. So if all calls to the static version of Validate would use _systemSettingService as a second parameter, with no exceptions, then making it non-static and saving the second parameter is IMHO the better alternative.

Usage of a DI container for the helper function will probably make the code longer, less readable, more complex and error prone, since you have to make sure the Resolve method will return the same systemSettingService object provided to MyController. IMHO it is better to use a DI container exclusively where it clearly makes things simpler.

In case Validate is a method of a helper class Validator, the same measures apply: passing the ISystemSettingService object directly to the method is not inherently wrong, but passing it to the constructor of Validator and making Validate non-static will probably result in more maintainable code.

Best Answer

Related Solutions

Java Concurrency – Handling Static Objects in a Web Application

C# – Unity Dependency Injection and Helper functions

Related Topic