I think a static class is better (in most cases) than implementing a singleton pattern - especially in a multi-threading environment :-}


>Yeah. I see your point. There are definitely cases where static would be applicable (what they call singletons I guess). I was more in doubt about more domain kind of classes like repository for example. From what I read now, implementing those as static would not be a good idea. Thanks.
>
>
>>>>>I wonder what the best practice would be when it comes to declare classes (and more importantly methods) static. I have found that in most cases pundits declare non static classes and methods where it would be perfectly workable to have them static.
>>>>>
>>>>>The way I see it is that static is easier to test no?
>>>>
>>>>http://msdn.microsoft.com/en-us/library/79b3xss3%28v=vs.80%29.aspx
>>>>Here's what MSDN says.
>>>>Basically, I use them the way MSDN suggests.
>>>
>>>So the wisdom is "when in doubt, refrain from declaring 'm static" right?
>>
>>Looking at the classes in the .NET Framework which are static should give you a good feel for what makes a good candidate for 'static'
>>
>>For example, in the 'System' namespace the Console, Math, Buffer, BitConverter, Convert and Tuple classes are all static.
>>
>>It would feel odd (and unnecessary) to have to instantiate one of those before using e.g.:

Convert c = new Convert();
>>c.ToBase64String(myBytes[]);

.... which also leaves an object that needs to be cleaned up by the garbage collector :-{