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

True

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

Maybe I'm 'over' namespacing a bit

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


I have a lot of extension methods and there are things I put in static classes (like IsEven(), RoundUpToMultiple(), RoundDownToMultiple()




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

There's always the danger, that changing/adding something may break another.

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


I think that's good. I also invest more time when I think - and I mostly do - I will be able to reuse it (whether really 'generic' or not)
This means an extra effort that willl pay off later - one hopes


In foxpro I had - still have - a generic treeview. I just feed it with (1) an entity cursor (id, desc) and (2) a relationcursor (ParentId, Id). ie do the 'heavy' thinking once, then stop thinking

I'm also a big fan of the facade pattern. Have I spent time on the streams (decorator). Now, I simply pass two streams (original and transformed) + an IEnumerble(transformation) to a class which has two static methods (DoTransform and DoInverseTransform) .. No more nested usings, trying to figure out whether to specify Write or Read to a Cryptostream, and tring to figure out whether to read or write to/from the stream



>Best,
>Viv

Cheers,