>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
I guess that applies to any language since methods were invented :-}

>(2) Namespaces. Name of them and how many
>Too many = having a lot of 'using'
Where it's my choice I tend to keep these to a minimum. Different ones for different layers - otherwise not unless there's a class name conflict.

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

Although 'cute' I think it's easy to overuse extension methods - useful with sealed classes tho. This is interesting:
http://blogs.msdn.com/mirceat/archive/2008/03/13/linq-framework-design-guidelines.aspx

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

But refactoring can help a lot. Bit risky with namespaces though (especially if you need to only change some occurrences of a given namespace). I used to be very leary of refactoring but I trust it a lot more now (but I still dump everything back into source contol if the operation I'm attempting looks dicey :-} )

>(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
>Takes a bit of work to add it to the classes that need it - but then it's only once

Not my subject I'm afraid - if anyone wants to unit test my bomb-proof code they can do it themselves (g,d&r). I did start to look at this but got bored:http://msdn.microsoft.com/en-us/magazine/cc163904.aspx
There's also stuff like NUnit (http://www.nunit.org/index.php) which, again, I know nothing about....

My hardest decisions at the moment is deciding when creating generic classes becomes worthwhile. I've built a generic WPF treeview that will accept any self-referencing table via it's EF entities. Works great but I only need it for three tables at the moment and the extra work means I've probably about broken even on development time. But it's there now for any other similar situation :-}

Best,
Viv