>That's moving the discussion a long way from the simpler question of naming conventions. I've mixed feelings about frameworks in general. Most frameworks I've looked at either do not have some feature that I might find essential or, conversely, come with a lot of baggage that I would not make use of. OTOH writing your own from scratch is, as you say, a major undertaking. But, in some ways, the .NET framework already provides many of the components usually found in these frameworks : data binding, change notification, validation etc. If you add in using things like EntityFramework and Prism then a lot of the work has been done.

What I learned in the early '90s, what, as most as possible, to always use wrappers. So, if the plateform changes, your code should be ok as is until you adjust the framework for the new platform. I wouldn't want to change all the .vb files I have a reference to XmlTextWriter for example, assuming I would have hardcoded it everywhere, if I would have to change to a new plateform. Right now, I only have to change it in my XML class at the framework level and simply have to recompile the client.

The same goes with the backend. Right now, I can support several backends, if the client wants to have a support for Oracle, for example, no code would have to be changed at the client level but would have to send a new Framework.dll to the client.