Acceptable use of static classes?

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
    }

}

开发者_如何学PythonAs 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

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.

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