>See my comments interspersed
>
>>A bit off topic, Viv
>>
>>I'm not into EF and WPF yet, just trying to find my way / get used to and discover
>>
>>Some of the tough ones
>>
>>(1) Finding a good name for classes/methods
>
>For methods, start with the good VerbNoun combination, such as WriteErrorLog or CalculateTax. Refactor as needed.

>
>>
>>(2) Namespaces. Name of them and how many
>>Too many = having a lot of 'using'
>
>Look at how the framework is organized. Pick one top level namespace and follow it down a couple of paths. That should give you some ideas.
>
>>
>>(3) Extension methods or static classes for a type of functionality
>>Too many extension methods clutter up intellisense
>>Putting things in static classes does not clutter up intellisense but you have to remember them
>
>Why static classes?

To avoid too many extension methods. I have a static Arithmetic class, like Math


>>(4) Doing it right the first time (Namespace/ class/method names)
>>It takes time to figure out how to organize them. And the day after I may have changed my mind
>
>That's called refactoring. Don't worry about getting things right the first time. After you've been working with .NET a while, more and more good names will come earlier in the process.
>
>>(5) testing - a lot of time involved
>>I have found a way - may not the best one
>>
>>All classes that need testing have a static method TestSuiteRun() which is conditionally compiled ( #define TESTSUITE in the project properties)
>>I have a static class TestSuite, with a Run() method that uses reflexion to find all the static TestSuiteRun() in all the classes and invoke them
>
>That doesn't sound like a good unit testing methodology. A great book is "The Art of Unit Testing"


Just ordered . Have taken amazon.co.uk for a change


>>
>>Takes a bit of work to add it to the classes that need it - but then it's only once