Data Classes

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

Cool, this is fun exercise. After using mine for a while, I have found that I want to change quite a few things. It works really well (although I never have polished it or did the error corrections that are needed for the masses).

To answer your specific question if I understand itright:

Quote:

---

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 expose a child collection as a collection object from the main object. For instance. I have a User table. I also have a Phone table. A User can have many Phones, so there is a One-To-Many relationship between User and Phone. In an object model, I expose it like this:

Code:

---

User myUser = new User();

// Do whatever to load your user with data.

//When I want to access the phone numbers this user has, I do this...
myUser.Phones[0].PhoneNumber

// I can loop through them easily using foreach...
foreach (Phone phn in myUser.Phones)
{
    // Do something with phn.
}

// I can bind Phones to a datagrid...
dgPhones.DataSource = myUser.Phones

// I can add new Phone objects to the myUser.Phones collection like this...
Phone newPhone = new Phone();
newPhone.PhoneNumber = "123-1231";
myUser.Phones.Add(newPhone);

//This should save any changes to user, along with any changes to any of the phones, added phones, or deleted phones.
myUser.Save();

---

That's what I was thinking of doing. Right now I work with the collections as an object of thier own and you have to pass them a key or a group of param. I have constructs that build a collection based on that paging sql you showed me and all kind of things. I'm hoping to just be able to use this to speed up development time for myself though. I spent six month on my last big data project and I can see where it could have been two instead.

I don't know if I'll ever try to sell this but I want to make as full fledged as I can. I may even try to do some kind of UML/XML work but I don't know. I would really like to get a working UserControl based forn generator working that takes a style sheet. Gen Pagers, New, Delete, Edit and so on. I thinking this really shouldn't be hard if you just use a basic layout(I mean add a row two cells a caption and a text box and a optional required validator. not to hard).. And, really even if you had to go in and set cell colors or the like that doesn't take long. Of course I would like to do a lot of things....

I take the same approach that hellswraith posted above. I'm actually in charge of the business layer dll on a rather large project at work. I've created objects and object collections for most of the database tables. I've build utility type programs that build the properties region based on the variable declarations and one program that builds the source file of a strongly typed collection based on the object type. These both output in any major .NET language. ;)

I've been considering building a utility that generates the actual objects themselves. It does seem like a lot of work but it would save a lot of time. At least up front it could include the variables, properties, constructor (taking the Id of the object), generic CRUD for the table, and a method that returns all of the records from the table as a strongly typed collection. Hmm... I'm getting ideas... :wave:

You want to look into generating code, have a look at this:
http://www.ericjsmith.net/codesmith/

Quote:

---

Originally Posted by hellswraith

You want to look into generating code, have a look at this:
http://www.ericjsmith.net/codesmith/

---

Looks pretty cool... I just seem to do things differently. I might take a stab at coding something similar to create classes and collection classes from a database. I'm going to have to think it out a little bit...

That's the reason I'm building my own tool. I just work in a diffrent way than most of the generators I've seen. Style....