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

... if you need different threads accessing the values of shared (static) properties right? Is that "done" at all?

>
>
>>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 :-{