I'm about to start working on a project I've had on hold for about 6 months. It's a User Interface(Drag Drop) that helps a programmer build data access namespaces/classes. It generates all the code and so on.

I've got most of this worked out. Well I'm having some trouble with the drag drop code between the tree views but I will get it figured or ask for help later. What I am really looking for input on is the data classes. I have a base model I use and a base collection for that model that work very well and provide some nice features like serial to file, restore from file and some useful data procedures to handle sql text or sql procedures. These are working and looking good. I've use the model in several projects and I am happy with the base foundation.

What I am having thoughts about is the data class that will be generated. For instance if a table is a child relation of another table should the child data object include every field of the parent as a property? Contain just a Key? Contain a nested object? Do Nested Objects Bind Properly, I've never tried?

I plan to use a SQL Text model for the first version and possible upgrade it to stored proc later. I'm doing this for two reasons it keeps me from having to generate and check SQL Procedure Names(good bit of code) and if I decied to be stingy and just have it output a dll my SQL is protected. I know is that stupid or what.... please not my SQL.....

So all in all I'm looking for suggestions. Or if anyone knows of any pitfalls to watch out for....