>>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?

Local variables in a static method are OK - the values are stored in the stack belonging to the thread. Changing static properties is not thread safe- if one thread changes the value then it can corrupt the value in another thread.

Simple example here (including how to make a static method thread safe) : http://odetocode.com/Articles/314.aspx

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