>>I am moving more and more from the idea from having the fwk doing everything developed by one vendor -
>>even with vfp fwks there was the need to tweak at the fwk level (but perhaps I am a compulsive tweaker...)
>>and with java/.net fwks spanning greater areas I see more and more benefit in the python approach to take well-defined
>>building blocks and glue them together. Write the necessary to glue in a different component if necessary.
>>
>I agree and to a great extent that is what this is evolving into for me. I like Devforce's extension of the EF, then there are module and region things in Prism that are very cool. MEF or Unity? Haven't decided yet on DI. MVVM has "frameworks" of its own - e.g. Cinch. Now I'm looking at Caliburn Micro and trying to evaluate if Actions rather than inheriting from iCommand is going to have implications down the line I won't like - and still have to check how well my DevExpress UI stuff is going to play with any of this.

I go for the big architectural picture - like always communicate with just the adjacent layer (the thing MS coorected iwith MVP and MVVM compared to MVC), communicate from the outside going in (and if there is really a UC for the other direction, comment twice as much as when the pain begins), build conglomerats of objects instead of god objects and so on. Also convention before configuration is a great time saver.
And if I see nontrivial amounts of non-DRY code, I ditch the package without further thought if that is not changed after a mail to the fwk authors pointing out a few of those places.