0

Have a class that was not originally meant to be static... 

public class SapApprovalHandler {

    private static SapGs3DataSet sapGs3DataSet;

    static SapApprovalHandler() {
        try {
            // Actually fills the dataset
            sapGs3DataSet = new SapGs3DataSet("SAP");
        }
        catch {
            throw new ApplicationException("Unable to create the SAP-GS3 DataSet");
        }
    }

    public static XElement ProcessApprovals(XElement SapData) {
        // Basically updates the dataset
    }

}

As I built the class, I decided that (1) I'd rather not refill the dataset unless I explicitly refreshed it, and (2) I'm the gatekeeper for these data; nobody else should be updating them. This class is called from within a WCF service.

Other than the dataset that I want to reuse, there's no state; every function on this class can be made static. But is it acceptable to make the class static? As opposed to instantiating it and having a member-level variable on the WCF to hold it. I'm not sure I can see a difference between the two approaches.

To make this less argumentative, let me ask: what are the drawbacks of making the class static? Reasons I might not want to do this.

Feel free to critique the approach in general; normally I would create the dataset within ProcessApprovals and dispose of it at the end of the call, but I really don't need to refresh the data frequently, if at all (I have a separate dataset with more transient data that I will refresh every time I update it; the SapGs3DataSet data really won't change).

Another approach would be to cache the dataset using, say, the Enterprise Library, which would let me set things such as expiration and methods to refresh the data.

I'll pick the answer based on the strongest argument why I shouldn't do this. If there aren't any strong arguments for not-doing it, I'll pick the answer with the best reasoning as to why it's okay.

TIA!
James

James King
  • 6,233
  • 5
  • 42
  • 63
  • 1
    possible duplicate of [When to use static classes and methods?](http://stackoverflow.com/questions/3251269/when-to-use-static-classes-and-methods) – Richard Anthony Hein Dec 09 '10 at 19:45
  • I've read some of the other articles here on static vs. non-static... I checked out the articles in your link, as well. I suppose I'm asking for a specific scenario here. The big thing that's tripping me up is the dataset... is it acceptable to have it as a static member? If so, the rest of the class can certainly be static. But a static dataset just rubs me a bit, even though my logic of why seems sound – James King Dec 09 '10 at 19:54
  • The big problem with a static field is that there's only copy of it. That gets to be a problem if you ever need to have multiple instances. And even worse if you find yourself dealing with multi-threading. There are better ways to only have one copy of a field. – ThatBlairGuy Dec 09 '10 at 20:28
  • Yeah, I'm leaning toward tvanfosson's answer of caching it outside of the class. That would let the class be static, but keep the dataset on hand. It would also let me specify code and rules to refresh the dataset. – James King Dec 10 '10 at 04:43

2 Answers2

2

I would consider using caching on the object rather than making it static. Static classes are typically harder to test and use in tests. Even making the data static increases the difficulty in running automated tests since you'll need to take extra steps to set up the data for the test, adding code just to address the testing needs. Using caching accomplishes the same effect and also allows the data to be flushed if space is needed for other purposes. You can automate the refilling of the object when flushed from the cache if need be so that your requests don't typically see any performance degradation.

tvanfosson
  • 524,688
  • 99
  • 697
  • 795
0

If you make it static, and then change your mind and want to keep some state, then you can't.

tato
  • 5,439
  • 4
  • 31
  • 27